Summary
Since #14, the OpenAleph adapter can call POST /api/2/match with the subject converted to an FtM Company entity. FtM matching weighs identifiers, countries and fuzzy name features — exactly the evidence class that FullCheck's reconciliation uses to draw dashed "likely same" POSSIBLY_SAME_AS edges between nodes that share a normalised name but no shared identifier.
Today match results only ever become source hits on the OpenAleph card. The open design question (deliberately parked when the match step shipped): should high-scoring, non-identifier-corroborated match candidates also surface as POSSIBLY_SAME_AS confidence edges in the FullCheck network graph?
Why it might be good
- FtM match scores encode more evidence than the current name-normalisation blocking (dates, countries, weak identifiers all participate).
- The corroboration flag already exists: hits carry
raw.identifier_corroborated. Corroborated hits are same entity (strong evidence); uncorroborated-but-high-score hits are possibly same — exactly the semantics of the dashed edge.
Why it needs care
- A false merge is a compliance liability; even a suggestive edge sourced from a fuzzy matcher needs careful confidence display. The existing rule — never a silent merge, always a visible judgement call for the analyst — must hold.
- Score comparability: FtM/BM25 scores are not comparable across subjects (they vary with name length and rarity). Any threshold must be relative, mirroring the 25%-of-top-hit gating in
match_entity() (backend/opencheck/sources/openaleph.py).
Where the code lives
- Reconciliation display transform:
frontend/src/lib/reconcile.ts; edge rendering in frontend/src/lib/bodsGraph.ts / frontend/src/components/BODSGraph.tsx (edge categories).
- Match gating:
match_entity() in backend/opencheck/sources/openaleph.py.
- QuickCheck already renders
possibly_same_entities in the report panel (collapsed to 2 rows behind "Show more"); any new edge source should feed the same structure.
Suggested first step
A design comment on this issue proposing: (a) which match hits qualify (uncorroborated, ≥ relative threshold), (b) how the edge is labelled and attributed in the UI (e.g. "FtM match, score N% of top"), (c) how an analyst dismisses or confirms the suggestion. Implementation after agreement — this is a discussion-first issue.
Summary
Since #14, the OpenAleph adapter can call
POST /api/2/matchwith the subject converted to an FtM Company entity. FtM matching weighs identifiers, countries and fuzzy name features — exactly the evidence class that FullCheck's reconciliation uses to draw dashed "likely same"POSSIBLY_SAME_ASedges between nodes that share a normalised name but no shared identifier.Today match results only ever become source hits on the OpenAleph card. The open design question (deliberately parked when the match step shipped): should high-scoring, non-identifier-corroborated match candidates also surface as POSSIBLY_SAME_AS confidence edges in the FullCheck network graph?
Why it might be good
raw.identifier_corroborated. Corroborated hits are same entity (strong evidence); uncorroborated-but-high-score hits are possibly same — exactly the semantics of the dashed edge.Why it needs care
match_entity()(backend/opencheck/sources/openaleph.py).Where the code lives
frontend/src/lib/reconcile.ts; edge rendering infrontend/src/lib/bodsGraph.ts/frontend/src/components/BODSGraph.tsx(edge categories).match_entity()inbackend/opencheck/sources/openaleph.py.possibly_same_entitiesin the report panel (collapsed to 2 rows behind "Show more"); any new edge source should feed the same structure.Suggested first step
A design comment on this issue proposing: (a) which match hits qualify (uncorroborated, ≥ relative threshold), (b) how the edge is labelled and attributed in the UI (e.g. "FtM match, score N% of top"), (c) how an analyst dismisses or confirms the suggestion. Implementation after agreement — this is a discussion-first issue.