@Gordon Collett here is the analysis. I am only posting this for you, because well, you will understand this. Please give suggestions for improving this. And/or definitely let us know your thoughts. Thank you :)

For the trio: This is a case where the system is intentionally choosing not to surface a mismatch. The name comparison library is designed to be permissive — it prefers false negatives (missing a real mismatch) over false positives (flagging a mismatch that isn't real). The reasoning is that showing users a spurious "name mismatch" issue on a correctly attached source is more harmful to trust than quietly accepting a fuzzy match. The Kari/Hans case is an edge case where that permissiveness goes further than intended.

Background

The consistency calculator compares a person's conclusion names against source record names using NamesUtil from tree-name-comparison-lib. NamesUtil is a Spring @Component  with these defaults (configurable via @Value ):

The low deletion cost is the root cause.

Step 1: Surname comparison passes

The surnames (after name segmentation) are approximately "Jensdatter Eldøy" vs "Jensdtr Eldøen".

compareNames first tries token-by-token (split on spaces). That fails — "eldøy" vs "eldøen" has a weighted distance of 2.0, and (5 - 2.0) / 5 = 0.60 < 0.8.

Then it tries the no-spaces concatenation path — "jensdattereldøy" vs "jensdtreldøen":

Weighted Levenshtein("jensdattereldøy", "jensdtreldøen"):
  - delete 'a'  → 0.1
  - delete 't'  → 0.1  (second 't' in "datter")
  - delete 'e'  → 0.1  (the 'e' in "datter")
  - y→e edit    → 1.0
  - insert 'n'  → 1.0
  Total ≈ 2.3

Ratio = (len("jensdtreldøen") - 2.3) / len("jensdtreldøen")
      = (13 - 2.3) / 13 ≈ 0.823

0.823 ≥ 0.80 → MATCH

The ultra-low deletion cost (0.1) makes "Jensdatter" → "Jensdtr" essentially free: three deletions × 0.1 = 0.3. This single fact drives the whole result.

Step 2: PatronymicUtil reinforces the match

For female name comparisons (getFemaleNameComparisons), PatronymicUtil.getPatronymicVersionsOfSurnames is called to expand the acceptable surname pool. "dtr" is a recognized female patronymic abbreviation ending, so "Jensdtr" generates additional candidate forms (e.g. "Jensen", "Jens") that are also added to the comparison. Even without this, Step 1 already returns MATCH.

Step 3: Given name mismatch gets buried by CROSS_MATCH

With surnameComp = MATCH and givenComp = NOT_MATCH ("Kari" ≠ "Hans"), getFullNameMatchComparisonResult fires this condition:

if (givenComp == NOT_MATCH || surnameComp == NOT_MATCH) → getFullNameCrossMatchComparisonResult

What CROSS_MATCH is for

CROSS_MATCH exists to handle a real problem with historical records: indexers sometimes put the surname in the given-name field or vice versa. For example:

A field-by-field comparison gives two NOT_MATCH results and would produce a spurious mismatch issue — but the names are clearly about the same person, just with transposed fields. CROSS_MATCH detects this by comparing each principal name part against the candidate's full name. If the parts are all present (just in different fields), it returns CROSS_MATCH and no issue is raised.

This is an intentional design choice: prefer not surfacing an issue over surfacing a wrong one.

What happens here

Inside the cross-match path, the library checks whether "Kari" appears anywhere in "Hans Jensdtr Eldøen" and vice versa. It doesn't — this isn't a field-transposition case, it's a genuinely different given name. But the fallback when no cross-match is found still applies CROSS_MATCH to any unresolved part when the other part already matched:

// givenComp is not a match type → replace with CROSS_MATCH
// surnameComp is a match type  → keep as MATCH
return new NameComparisonResult(CROSS_MATCH, MATCH, ...)

And in ConsistencyCalculator.scoreNameComparison (line 369):

case MATCH, CROSS_MATCH -> {
    // no issue
}

CROSS_MATCH is treated the same as MATCH — no issue is raised. The "Kari" vs "Hans" mismatch never surfaces. This is where the permissiveness goes further than intended: the fallback was designed for field-transposition cases, but it also swallows genuine given-name mismatches when the surname already matched.

Summary

Two separate permissive choices compound to suppress the mismatch:

Each choice is reasonable on its own. Together they create a path where a source attached to the wrong person produces no issue.

To make this flag, you would need to raise the threshold above 0.823, increase the deletion cost, or add explicit handling when the conclusion and source given names differ by gender.

@Gordon Collett Thanks!

I will put it on the items to consider when we revisit some of the rules for the Quality Score.

@Gordon Collett Thanks for the message.

We believe this is an unintended consequence of an update that was made, and are looking into it.

Thanks again!