Routing rules that survive model-risk review.
A rule that acts on a silently blended field cannot be defended. Publish which fields are declared, which are modelled, and how the models test.
We publish declared and modelled as separate fields and test the models against the declared set, so a routing rule can weight record evidence and model prediction differently rather than acting on a silent blend.
Your second line will ask three questions about any field in an automated rule. Where did it come from. How was it tested. What happens when it is wrong. A rule that cannot answer all three does not survive the review, and it should not.
Declared and modelled, never blended
The single most common failure is a field that silently mixes record evidence and a model prediction. It looks like one clean value. It is two different kinds of claim wearing the same coat, and a rule that acts on it cannot say which one it trusted.
So we publish them apart. The declared field carries record evidence. The predicted field is modelled and tested against the declared set. Your rule reads both and weights them as your appetite requires.
IF basement_predicted = TRUE AND basement_declared = NULL -> route to desktop before AVMA flag that is wrong one time in five is not a rule, it is a story you will have to tell later.
A field that states its own error rate
The point of separating declared from modelled is that a modelled flag can be honest about how often it is right. A blanket rule - no AVM where a basement is suspected - over-declines because it treats a noisy signal as certainty. A flag that publishes its tested accuracy lets you route the doubtful cases instead of rejecting them.
We hold the accuracy figure per release and supply it on request rather than printing a flattering number in marketing copy. Your model-risk team gets the figure they can actually use, dated, per segment.
The documentation exists before you ask
- -Source attribution per field - where each value came from.
- -A data dictionary your second line can read without a translator.
- -Methodology documentation written for model-risk review, not for a brochure.
- -Change-logged releases, so old fields keep working and your models do not go haywire because we shipped.
If your process needs a data-sharing agreement, a due-diligence questionnaire and three committees, that is fine. We have been through them before. The rule you build on this data should be one you would be comfortable explaining, line by line, to the person whose job is to doubt it.