Recency (Last Update Date, also known as LUD) Rule

This rule selects the value within the attribute that was posted most recently. You might think that the rule need only compare the LastUpdateDate of the crosswalks that contribute to the attribute to find the most recently updated crosswalk, then use the value that comes from that crosswalk as the Operational Value (OV). But the real process is a bit more complex. There are three timestamps associated with an attribute value that play a role in determining the effective LastUpdateDate for the attribute value. They are:

• Crosswalk Update Date - this is updated at the crosswalk level and reflects the best information about when the source record was most recently updated.
• Crosswalk Source Publish Date - this is also updated at the crosswalk level but entirely under your control. It is an optional field you can write, to capture the business publish date of the data. E.g suppose you receive a quarterly data file. You might post the value of 3/31/2020 into this field.
• Single Attribute Upate Date - This is an internally managed timestamp associated with an actual value in the attribute’s array of values. It is updated separately from the crosswalk.updateDate if the value experiences a partial override operation in which case it will be more recent than the crosswalk.

The Recency rule calculates the effective timestamp of an attribute value to be the most recent of the three values discussed above: sourcePublishDate, SingleAttrUpdateDates, LastUpdateDate. Once it calculates that for each value in the attribute, it returns the most recent attribute value(s) as the OV of the attribute.

Selectable in the UI?: Yes

Source System Rule

This rule allows you to organize a set of sources in order of priority, as a source for the OV. You will use the gear icon to arrange the sources. The gear icon will appear when you choose the Source System rule. Using this rule, the survivorship logic will test each source in order (starting at the top of the list). If the source tested has contributed a value into the attribute, then that value will be the OV of the attribute. If it has not, then the logic will try the next source in the list. This cycle will continue until a value from a source has been found or the logic has exhausted the list. If there are multiple crosswalks from the same source, then the OV will be sourced from the most recent crosswalk.

Selectable in the UI?: Yes

Frequency Rule

This rule calculates the OV as the value within the attribute that is contributed by the most number of crosswalks.

Selectable in the UI?: Yes

Aggregation Rule

If an attribute has more than one value and Aggregation is chosen for the survivorship rule, then all unique values held within the attribute are returned as the OV of the attribute. This is easy to see in the UI.

Selectable in the UI?: Yes

OldestValue Rule

The Oldest Value strategy finds the crosswalk with the oldest create date. All values within the attribute that were provided by this crosswalk are selected as the OV. Other attributes are not affected.

Selectable in the UI?: Yes

MinValue Rule

Selectable in the UI?: Yes

MaxValue Rule

Selectable in the UI?: Yes

OtherAttributeWinnerCrosswalk Rule

This rule leverages the crosswalk that was chosen by the outcome of another attribute’s survivorship. Example suppose you have a Name attribute and an Address attribute, and you feel they should be tightly coupled. And so you want to ensure that the address that is selected as the OV comes from the same crosswalk that produced the OV of the name.

Selectable in the UI?: Yes, but not practical to do so. It must be configured in the L3 configuration.