How to Configure Operators & Functions with Rule Builder

Overview

Use Rule Builder to create validation rules that help maintain appraisal data quality. When appraisal data does not meet your defined criteria, Rule Builder generates a finding. This guide explains the operators, functions, and expressions used to evaluate appraisal data and identify discrepancies when defined conditions are not met.

How to Configure Operators and Functions

Core concept: A rule describes the expected valid state of appraisal data. The rule stays silent when the data meets the expectation and creates a finding when the expectation is not met.

Audience: Business users, rule authors, and administrators who create appraisal review rules.

Use this guide to: select the correct operator, understand when a rule will fire, and combine conditions using expression types such as all, any, implies, and forEach.

You write	You are asserting	A finding is created when
GREATER_THAN 20	The value should be above 20.	The value is 20 or less.
STRING_EQUALS "TX"	The state should be TX.	The state is anything other than TX.
IS_TRUE	The flag should be true.	The flag is false.
EXISTS	The field should be populated.	The field is missing or blank.

1. How rules evaluate data

Rule Builder rules should be written as positive expectations. In other words, configure the condition that should be true. If the appraisal data does not satisfy that condition, the rule fires and creates a finding.

Best practice: Avoid writing rules as error statements. Instead of thinking "flag LTV over 95" think "Loan-to-value should be
less than or equal to 95." Then choose the operator that represents the expected valid state.

2. Comparison modes

Most operators compare the field value from the appraisal to a right-hand value. That right-hand value can be a fixed value you enter or another field from the same appraisal.

Mode	What it compares against	When to use it	Example
Literal	A fixed value you type.	Use when the threshold or allowed value is known and constant.	Loan-to-value should be <= 95.
Field-to-field	Another field from the same appraisal.	Use when two fields must relate to each other.	Inspection date should be after order date.

Mode

What it compares against

When to use it

Example

Literal

A fixed value you type.

Use when the threshold or allowed

value is known and constant.

Loan-to-value should be <= 95.

Field-to-field

Another field from the same appraisal.

Use when two fields must relate to each other.

Inspection date should be after

order date.

Some operators are literal-only because they require a typed value, such as BETWEEN, DATE_BETWEEN, WITHIN_LAST_DAYS, OLDER_THAN_DAYS, MATCHES, the length operators, IS_TRUE, and IS_FALSE. Calculations are field-to-field-only and are documented as a potential capability.

3. Numeric operators

Use numeric operators for dollar amounts, percentages, counts, square footage, adjustment values, and similar number fields.

Operator	Expected valid condition	Finding created when
GREATER_THAN	Value is strictly above your number.	Value is equal to or below your number.
GREATER_THAN_EQUAL	Value is at least your number.	Value is below your number.
LESS_THAN	Value is strictly below your number.	Value is equal to or above your number.
LESS_THAN_EQUAL	Value is at most your number.	Value is above your number.
EQUALS	Value exactly matches your number.	Value is different.
NOT_EQUALS	Value is anything except your number.	Value equals your number.
BETWEEN	Value is inside the range, including both endpoints.	Value is below the low bound or above the high bound.

BETWEEN format: enter the low and high values separated by a semicolon, such as 0;25. Both endpoints are accepted.

Example:
Field: LoanToValue
Operator: LESS_THAN_EQUAL
Value: 95
This rule asserts that LoanToValue should be 95 or less. It creates a finding when the value is greater than 95.

4. Text operators

Use text operators for state codes, identifiers, comments, form numbers, status values, free text, or code-list values. Text comparisons are case-sensitive, so TX and tx are treated as different values.

Operator	Expected valid conditon	Finding created when
STRING_EQUALS	Text matches exactly.	Text differs, including capitalization.
STRING_NOT_EQUALS	Text is anything except your text.	Text equals your text.
STRING_CONTAINS	Text includes your snippet.	Snippet is not found.
STRING_NOT_CONTAINS	Text does not include your snippet.	Snippet is found.
STRING_STARTS_WITH	Text begins with your prefix.	Text does not start with it.
STRING_ENDS_WITH	Text ends with your suffix.	Text does not end with it.
IN_LIST	Text is one of the allowed values.	Text is not in the list.
NOT_IN_LIST	Text is none of the listed values.	Text is in the list.
MATCHES	Text fully matches your pattern.	Text does not match the pattern.
LENGTH_EXCEEDS	Text is longer than the reference text.	Text is the same length or shorter.
LENGTH_LESS_THAN	Text is shorter than the reference text.	Text is the same length or longer.
LENGTH_EQUALS	Text length equals the reference text.	Text length is different.
List formatting: For IN_LIST and NOT_IN_LIST, use comma-separated values without spaces, such as TX,CA,NY. Values are matched exactly, so spaces after commas may become part of the value.


Length operator nuance: Length operators compare the field length to the number of characters in the value you type, not to the numeric value itself. To test longer than 5 characters, enter a 5-character placeholder such as ABCDE.

5. Boolean operators

Use Boolean operators for yes/no or true/false indicators.

Operator	Expected valid condition	Finding created when
IS_TRUE	The flag is true.	The flag is false.
IS_FALSE	The flag is false.	The flag is true.
EQUALS	Two flags differ	The two flags differ.
NOT_EQUALS	Two flags differ.	The two flags match.
IS_TRUE and IS_FALSE are literal-only. To compare one indicator to another indicator, use EQUALS or NOT_EQUALS.

6. Date and date/time operators

Use date operators for effective dates, inspection dates, order dates, contract dates, and other date or date/time fields. Dates use ISO format: yyyy-MM-dd.

Operator	Expected valid condition	Finding created when
EQUALS	Date is the same as the reference date.	Date is different.
NOT_EQUALS	Date is different from the reference date.	Date is the same.
BEFORE	Date is before the reference date.	Date is on or after the reference date.
AFTER	Date is after the reference date.	Date is on or before the reference date.
DATE_BETWEEN	Date is within the start and end window.	Date is outside the window.
WITHIN_LAST_DAYS	Date is within the last N days.	Date is older than N days ago.
OLDER_THAN_DAYS	Date is at least N days in the past.	Date is more recent than N days ago.
DATE_BETWEEN format: enter start and end dates separated by a semicolon, such as 2025-01-01;2025-12-31. Both endpoints are accepted.
WITHIN_LAST_DAYS and OLDER_THAN_DAYS: enter the number of days. These values are evaluated against today's date.

7. Presence operators

Presence operators check whether a value is supplied. They do not require a comparison value.

Operator	Expected valid condition	Finding created when
EXISTS	The field is present and populated.	The field is missing or blank.
NOT_EXISTS	The field is absent or blank.	The field is present with a value.
Blank values: A field that is present but empty is treated the same as a missing field for EXISTS.

Complex or container elements are sections that hold child elements but do not have values of their own. Rule Builder authors rules against scalar fields today, such as numbers, text, dates, and yes/no fields.

8. Planned or potential capabilities

The following capabilities are documented for awareness but are not currently exposed in the Rule Builder UI based on the provided source material.

Capability	Purpose	Current status
Repeat/count operators	Count how many times an element or section appears and compare the count to an expected whole number.	Potential capability. Not exposed in the UI today.
Calculations on numeric values	Apply arithmetic steps to a numeric field before comparing it to another field.	Potential capability. Not used by live rules or available in the UI today.
forEach index targeting	Run a loop against one specific occurrence by position.	Potential capability. Not exposed in the UI today.

9. Expression types, also called functions

Expression types combine multiple conditions or repeat checks across matching items. They determine how child conditions roll up into one rule result.

Expression type	Use when	Finding created when
all	At least one acceptable path is enough, like logical OR.	Any child condition is violated.
any	At least one acceptable path is enough, like logical OR.	Every child condition is violated.
implies	A requirement applies only when a trigger condition is true.	The trigger is true and the requirement is violated.
forEach	The same checks must run for each item in a repeating section.	Any iterated item violates its child conditions. One finding can be created per item.

Examples:

all: Loan-to-value should be <= 95 and gross adjustment should be <= 25. The rule fires if either check fails.
any: The form should be either 1004 or 1073. The rule fires only if the form is neither option.
implies: If the property is in Texas, then loan-to-value should be <= 90. The rule fires only when the property is in Texas and the LTV exceeds 90.
forEach: For each sales contract, contract amount should exist. The rule can create a finding for each contract missing an amount

forEach rule of thumb: Keep each per-item check inside the item being looped over. The field path used by the child check should live
under the same repeating item selected by the forEach scope.

10. Quick decision guide

Validation goal	Recommended operator or expression
Verify a required value exists	EXISTS
Verify a value is blank or absent	NOT_EXISTS
Compare numeric values	GREATER_THAN, GREATER_THAN_EQUAL, LESS_THAN,LESS_THAN_EQUAL, EQUALS, NOT_EQUALS
Validate a numeric range	BETWEEN
Compare exact text	STRING_EQUALS or STRING_NOT_EQUALS
Check for keywords or phrases	STRING_CONTAINS or STRING_NOT_CONTAINS
Validate one of several allowed text values	IN_LIST
Validate a yes/no indicator	IS_TRUE or IS_FALSE
Compare dates	BEFORE, AFTER, EQUALS, NOT_EQUALS, DATE_BETWEEN
Require multiple conditions	all
Allow multiple valid outcomes	any
Create conditional logic	implies
Validate every item in a repeating section	forEach

11. Authoring checklist

Checklist:

Write the condition as the valid expected state.
Confirm the field type before selecting an operator.
Use literal comparisons for fixed thresholds and field-to-field comparisons when values should relate to each other.
Use EXISTS when a value must be present before validating its content.
Use IN_LIST without spaces after commas when listing allowed values.
Use implies for conditional requirements, such as state-specific or product-specific rules.
Use all when every requirement must pass and any when one of several acceptable outcomes is enough.
Use forEach only when the same check should apply to each item in a repeating section.

Source: OPERATORS-AND-EXPRESSION-TYPES.md, provided by the user.

Outcome

By using this resource to design your validation logic, you can successfully build positive, robust appraisal review rules that ensure high-quality data. You are now prepared to select and apply the appropriate numeric, text, Boolean, date, or presence operators for any field type. Additionally, you can combine multiple validation rules with complex expression types like all, any, implies, and forEach to automate your complete review workflow.