Design a String-Rule Validator for Transaction Records

Design a validator for transaction records using rules supplied as strings. Example rule concepts prohibit a particular credit-card name or merchant name. Explain how you would define the rule language, parse transactions, evaluate rules, and test the behavior. ### Constraints The exact rule grammar, transaction encoding, combination semantics, and output format are unspecified. The examples establish name-based restrictions but do not define a complete language. Do not execute rule strings as unrestricted code. This is a specification-and-implementation discussion rather than a fixed console contract. ### Clarifying Questions - How are field names, operators, values, quoting, and escaping represented in a rule? - Must a transaction satisfy every rule, any rule, or an explicitly grouped expression? - Are name comparisons case-sensitive, and what happens when a field is missing? - Should output contain accepted records, rejected records, or per-rule explanations? ```hint Separate parsing from evaluation A malformed rule and a well-formed rule that rejects a transaction are different outcomes. ``` ### What a Strong Answer Covers - An explicit, bounded rule grammar and validated transaction schema. - Typed evaluation, missing-field policy, deterministic results, and safe error handling. - Tests derived from the declared contract and a strategy for reviewing generated implementation changes. ### Follow-up Questions - How would an unknown field or unsupported operator be reported? - How would you retain useful rejection explanations without exposing unnecessary transaction data?