A test can carry configuration as well as a predicate.
Severity decides whether failing records create a warning or an error. Use a warning when the team has explicitly accepted that condition for monitoring; changing severity doesn't repair the data. Read the failure count before deciding whether a build is safe to use.
A where configuration scopes the rows tested. For example, amount may be required for paid orders while remaining unknown for a pending order. That's a different promise from requiring amount everywhere. State the scope in the model description so downstream users know what passed.
Be careful with status normalization and NULL: a filter matches only records whose condition is true. A missing or differently cased status can fall outside a test unless the model and rule account for it.