Post by Jerry McClintock

**Realistic Policy Rule Examples for CLE (JsonLogic)** Here are practical examples based on common regulated workflows. These are illustrative — you can author them in the rule editor or as code. ### 1. BFSI — High-Risk Transaction Block (P1) ```json { "if": [ { "and": [ { "==": [ { "var": "actionType" }, "wireTransfer" ] }, { ">": [ { "var": "amount" }, 50000 ] }, { "!=": [ { "var": "userRole" }, "seniorApprover" ] } ] }, "P1", "P3" ] } ``` **Meaning**: Block large wire transfers unless done by a senior approver. ### 2. Healthcare RCM — PHI Data Handling (P2 Force HITL) ```json { "if": [ { "==": [ { "var": "dataCategory" }, "PHI" ] }, "P2", "P3" ] } ``` **Meaning**: Any output involving protected health information forces human review before proceeding. ### 3. AML / Fraud — Risk Score Escalation (P2) ```json { "if": [ { ">=": [ { "var": "riskScore" }, 75 ] }, "P2", "P3" ] } ``` **Meaning**: High-risk transactions require human sign-off. ### 4. Combined Rule — Multiple Conditions (P1) ```json { "if": [ { "or": [ { "==": [ { "var": "transactionType" }, "highRiskCountry" ] }, { "and": [ { ">": [ { "var": "amount" }, 100000 ] }, { "==": [ { "var": "verificationStatus" }, "incomplete" ] } ] } ] }, "P1", "P3" ] } ``` **Meaning**: Block high-risk country transactions or large incomplete ones. ### How These Work in Practice - Rules are stored versioned and can be updated safely (new version deployed without downtime). - CLE evaluates them in order or by priority. - Every evaluation (pass or fail) produces a signed execution certificate for the audit trail. These are the kinds of rules you can author in the policy editor or import as JSON. They keep enforcement deterministic and auditable.