Your filter is being matched, but it is not doing what you expect because of how Reltio evaluates survivorship filters and OtherAttributeWinnerCrosswalk.
In your explain response, both No Information and Female show:
"matchedFilters": [
{
"notIn": [
{
"uri": "configuration/entityTypes/Patient/attributes/gender",
"value": "NI,No Information"
}
]
}
]
That means Reltio is saying: this survivorship rule is applicable. It does not mean "the NI value was excluded."
Why No Information is still winning
Your main rule is:
"survivorshipStrategy": "OtherAttributeWinnerCrosswalk",
"primaryAttributeUri": "configuration/entityTypes/Patient/attributes/canContribute"
Reltio's official documentation says OtherAttributeWinnerCrosswalk gets the winner crosswalks from the primary attribute. If the current attribute value has any of those winner crosswalks, that value can become OV. (Reltio)
Your canContribute rule is:
{
"attribute": "configuration/entityTypes/Patient/attributes/canContribute",
"valuesPriorityOrder": ["Y"],
"survivorshipStrategy": "ValueBasedPriority"
}
Both records have:
canContribute = Y
So both records' crosswalks can become winning crosswalks for canContribute. Then gender uses those winning crosswalks through OtherAttributeWinnerCrosswalk.
At that point, both gender values are eligible:
Record 1: canContribute = Y, gender = Female
Record 2: canContribute = Y, gender = No Information
Because there is more than one eligible winner, your fallback is triggered:
"fallbackUsingCriteria": "MORE_THAN_ONE",
"fallbackStrategies": [
{
"attribute": "configuration/entityTypes/Patient/attributes/gender",
"survivorshipStrategy": "LUD"
}
]
Since No Information was loaded on Day 10 and Female was loaded on Day 1, the LUD fallback selects No Information.
So the actual behavior is:
canContribute winners = Record 1 and Record 2
gender candidates = Female and No Information
MORE_THAN_ONE fallback = true
LUD winner = No Information
That matches your explain API output.
The filter is also likely configured incorrectly for a lookup
Your gender is lookup-backed. Reltio documentation says that when a lookup attribute is used in a survivorship filter, the comparison depends on resolveLookupCode. If resolveLookupCode = true, the filter is applied to the lookup code. If resolveLookupCode = false, the filter is applied to the stored/raw value. Reltio recommends using resolveLookupCode = true and filtering by lookup code. (Reltio)
Your response shows:
"value": "No Information",
"lookupCode": "NI",
"lookupValue": "No Information"
But your filter says:
"value": "NI,No Information"
For notIn, this means "not in the list containing NI and No Information" only if Reltio parses the comma-separated value the way you intend. The official support example for in uses comma-separated values like "Mobile,Work"; however, with lookup-backed attributes, the correct value still depends on resolveLookupCode. (support.reltio.com)
If your tenant or attribute has resolveLookupCode = true, use only the lookup code:
"filter": {
"notIn": [
{
"uri": "configuration/entityTypes/Patient/attributes/gender",
"value": "NI"
}
]
}
If resolveLookupCode = false and the stored value is the lookup value, use:
"filter": {
"notIn": [
{
"uri": "configuration/entityTypes/Patient/attributes/gender",
"value": "No Information"
}
]
}
But even after fixing that, the rule may still not solve your use case
The key point: survivorship filters are used to determine which survivorship mapping/rule applies. They are not always a simple "remove this attribute value from consideration" mechanism, especially when your rule is driven by OtherAttributeWinnerCrosswalk.
Your business requirement sounds like:
Prefer gender values from canContribute = Y records,
but never allow NI / No Information to win if another meaningful gender exists.
A safer pattern is to make the fallback itself prefer meaningful gender values, rather than relying only on the outer filter.
For example, use ValueBasedPriority for gender as a fallback, with real gender values ranked above NI:
{
"attribute": "configuration/entityTypes/Patient/attributes/gender",
"primaryAttributeUri": "configuration/entityTypes/Patient/attributes/canContribute",
"survivorshipStrategy": "OtherAttributeWinnerCrosswalk",
"fallbackUsingCriteria": "MORE_THAN_ONE",
"fallbackStrategies": [
{
"attribute": "configuration/entityTypes/Patient/attributes/gender",
"survivorshipStrategy": "ValueBasedPriority",
"valuesPriorityOrder": [
"Female",
"Male",
"Other",
"Unknown",
"NI"
]
}
]
}
If resolveLookupCode = true, Use lookup codes in valuesPriorityOrder, not lookup display values.
Proposed Next Actions for Considerationor Considerationor Consideration
Check your physical configuration for resolveLookupCode at tenant level and for the gender attribute. Then change the filter value to match the actual stored comparison form: probably NI, not "NI,No Information".
Also review whether the filter belongs on the main OtherAttributeWinnerCrosswalk rule or on a fallback/alternate survivorship rule. Based on your explain output, the fallback LUD is what ultimately selected Day 10 No Information, so changing only the top-level filter may not produce the result you want.
------------------------------
De'Norgil Dixson
Reltio Customer Architect
------------------------------