Generalize bridge matching to support custom bridge sources

[paynejd]

Summary

OCL's bridge matching currently hardcodes CIEL as the only bridge source. We need to parameterize this so any interface terminology modeled like CIEL (concepts + mappings to target repos) can be used as a bridge source. This enables evaluation of new bridge content and opens the bridge matching pattern to the OCL community.

Background

Bridge matching = semantic search on a bridge source, filtered to concepts mapped to the target repo. The search mechanics are already source-agnostic — only guards and string comparisons are CIEL-specific.

We have a second bridge-like source ready for evaluation. Rather than scripting around the Mapper, we can parameterize the bridge source URL so core users can configure it directly in the algorithm settings.

Approach

Add a "Bridge Source URL" field to the bridge algorithm settings panel (visible only to core_user group members), defaulting to /orgs/CIEL/sources/CIEL/. Changes span 3 repos:

oclapi2 (1 file)

• core/concepts/views.py:841-844 — Generalize is_bridge detection from CIEL-specific to any source. This only affects the search_meta.algorithm label (from ocl-ciel-bridge to ocl-bridge). Backward compatible.

react-bridge-match (1 file)

• src/BridgeMatch.jsx:10 — Remove the CIEL+LOINC guard from canBridge. Keep mappedRepos.includes(repo.url) check (validates bridge maps to target) and auth group check. The rest of the component already uses bridgeRepoURL prop generically.

oclmap (5 files)

• MapProject.jsx — Read bridge source URL from algo config instead of hardcoding. Replace CIELMappedSources state with a map keyed by bridge URL. Replace ~10 'ocl-ciel-bridge' string comparisons with .includes('bridge') or type-array checks.
• MultiAlgoSelector.jsx — Add "Bridge Source URL" text field in expanded settings for bridge-type algos, gated to isCoreUser.
• Concept.jsx:187 — Change === 'ocl-ciel-bridge' to .includes('bridge').
• Candidates.jsx:615 — Same pattern.
• ConfigurationForm.jsx:57 — Accept both 'ocl-bridge' and 'ocl-ciel-bridge' types. Thread isCoreUser to MultiAlgoSelector.

What does NOT change

• $match search mechanics (ES queries, vector search, reranking) — already source-agnostic
• Bridge result display (cascade mapping chain visualization) — uses data fields, not CIEL-specific logic
• AI Assistant analysis — treats all candidates uniformly
• Export format — formats from mapping data generically

Deployment order

1. oclapi2 — generalize is_bridge (backward compatible)
2. react-bridge-match — remove CIEL guard
3. oclmap — parameterize references, add UI field

Acceptance criteria

• Existing CIEL bridge projects work unchanged
• Core user can enter custom bridge source URL in algo settings
• Custom bridge results display with same visual chain format
• Multi-algo eval works (reranking + export include custom bridge results)
• Non-core users cannot see the bridge source URL field
• All changes submitted via PRs with review

[paynejd]

cc @filiperochalopes

[snyaggarwal]

@paynejd this is merged and deployed

[ocl-automation]

Automated Triage — 2026-04-14

Dimension	Score
Complexity	4
Scope	4
Clarity	3
Dependency	2
Risk	3

Decision: decision/planning-needed
Type: type/feature
Signals: signal/large-scope

Significant architectural change requiring parameterization of hardcoded bridge source logic across multiple components (API and mapper). Clear goal but implementation details like interface design and backward compatibility are unspecified. Moderate risk as incorrect bridge matching could affect semantic search results.

---

Generated by ticket-triage pipeline v3. Model: anthropic/claude-sonnet-4 (openrouter).