Rule Inspector

The Rule Inspector is the diagnostic surface inside each automation rule. It answers the question every automation user eventually asks: “why didn’t my rule fire?” For each rule, the inspector shows recent evaluation results with the specific reason a rule fired, skipped, or failed. This page covers how to read the inspector, what the SKIP reasons mean, and how to use it for tuning rules.

---

Accessing the Inspector #

1. Go to TrustLens → Automation
2. Click any rule in the list
3. Scroll to the Recent Activity panel

The panel shows the last 10 evaluations of this specific rule. For a fuller history, see the Automation Log under Reports.

---

What an Evaluation Entry Shows #

Field	Description
Timestamp	When the trigger event arrived
Trigger event	The triggering event ID (e.g. order_placed)
Target	Customer hash and/or order ID
Outcome	FIRED / SKIPPED / FAILED
Reason	Specific reason for the outcome
Actions dispatched	Count and detail per action

---

The Three Outcomes #

FIRED #

All conditions passed; actions were dispatched. The “Actions” subsection shows each action’s individual result.

SKIPPED #

At least one condition didn’t pass, or a meta-rule blocked the firing. The “Reason” tells you exactly which:

• Condition not met: trust_score > 50 — the named condition evaluated false
• Cooldown active — rule fired recently for this target; cooldown period not yet expired
• Rule disabled — the rule’s enable toggle is off
• Engine disabled — the entire automation engine is off

FAILED #

An action failed to execute. Each failed action’s reason is shown:

• Webhook returned 500 — receiver error
• Webhook timeout (10s)
• Email delivery error
• Order already cancelled — Cancel Order action on already-cancelled order

Failed actions retry per the standard retry policy; the inspector shows the latest attempt result.

---

The “Condition not met” Reason #

The most common SKIP reason. Format: Condition not met: {field} {operator} {expected_value}, actual: {actual_value}.

Example: Condition not met: trust_score < 30, actual: 47.

This tells you exactly why the rule didn’t act. If the rule was supposed to fire on customers with score < 30 but the customer’s actual score is 47, the rule is working correctly — the customer just doesn’t meet the criterion.

The inspector evaluates conditions in order and stops at the first that fails. If multiple conditions would have failed, you’ll only see the first. After fixing that, you may see a new “Condition not met” for the next condition.

---

Common Investigations #

“My rule should be firing but isn’t” #

1. Open the rule and check Recent Activity
2. Look for SKIPPED entries on the customer who should have triggered the rule
3. The Reason tells you which condition rejected the trigger
4. Either:
   • Fix the condition (it’s wrong)
   • Fix the customer’s data (the field value is unexpected)
   • Wait — the trigger hasn’t actually fired yet for this customer

“My rule is firing too often” #

1. Open the rule and check Recent Activity
2. Look for repeated FIRED entries on the same target
3. Consider adding a cooldown to prevent rapid re-fires
4. Or tighten conditions to fire on a narrower cohort

“My webhook action is failing” #

1. Open the rule and check Recent Activity for FAILED entries
2. The reason shows HTTP status or timeout
3. Test the webhook URL with a manual request
4. Verify HMAC signature handling on the receiver side
5. Check whether the receiver is reachable from your WordPress server (firewall, internal IP, etc.)

“My rule fired but the action didn’t happen” #

1. FIRED status confirms conditions passed and actions were dispatched
2. Open the Actions subsection — was the specific action’s result success or failure?
3. If success but the downstream effect isn’t visible, the action did fire but the receiver did something unexpected (silent failure, mis-routing, etc.)

---

The Automation Log #

For a fuller history than the 10-entry inspector view, see TrustLens → Settings → Automation → Activity Log. The log is searchable by:

• Rule
• Customer
• Trigger event type
• Outcome (FIRED / SKIPPED / FAILED)
• Date range

Default retention is 90 days. Configurable up to 365 days.

---

Inspector vs Validator #

The save-time validator catches structural problems before a rule is even active — unsatisfiable conditions, schema violations, missing fields. The inspector catches runtime problems — conditions that could be true but aren’t on the events you’ve seen, action failures, cooldown rejections.

The two together give you both pre-flight and in-flight diagnostics. A rule that passes the validator and fires correctly in the inspector is doing what you intended.

---

Reading SKIP Reasons in Context #

SKIP isn’t a failure — it’s the engine doing its job. A rule like “fire a webhook (e.g. to a Slack incoming webhook URL) when score drops below 30” should SKIP every event where the score is 50, 60, 70. Those skips are correct.

Look for SKIP reasons that are wrong:

• The condition references a field that doesn’t exist in the trigger context (rare; usually caught by validator)
• The expected value type doesn’t match (e.g. comparing string to integer)
• A field’s actual value isn’t what you expected (data quality issue)

If every recent evaluation is SKIPPED for the same reason, the rule may never fire under your current store conditions — consider whether the conditions still make sense.

---

Testing Rules #

To test a rule without waiting for real events, use the “Test Rule” button on the rule edit page. The dialog lets you simulate a trigger event with sample context, and shows the evaluation result inline — same outcome semantics as the inspector but on demand.

Useful for verifying rule logic before enabling, especially for rules with conditions on rare events (e.g. chargeback ratios crossing thresholds).