Inspecting the Values Used in Filters and Calculations

A common need when validating a rule application is to see the actual values flowing through each filter/condition and calculation at runtime. For example, the specific field value behind the logic that decided a loan passed. InRule does not expose this as a single "dump every value" switch; instead it offers three documented mechanisms, each suited to a different situation. This page explains what each one captures and links to the detailed reference for it.

At a Glance

Approach	Granularity	Production-safe?	Captures values automatically, or by design?
Rule Tracing	Highest: every evaluation step	No (debug/validation only)	Automatic for traced elements
Execution Log (RuleValues, StateChanges, Execution)	Element- and state-level	RuleValues adds memory/perf cost	Automatic, read back via SDK
Notifications / Metrics	Only what you author	Yes	Author-defined per field/expression

1. Rule Tracing (Most Granular)

Rule Tracing records the chronological sequence of activities the engine performs while evaluating rules. When trace output is read as Trace Events, each event carries Evaluations (the decomposition of the source-syntax rule and its evaluated results). The underlying trace activity/frame also exposes Aspects, simple name/value pairs (for example, a Result and its value), which is where the operand values behind a specific filter or calculation are exposed.

Enable it in irVerify, or programmatically with EngineLogOptions.RuleTrace. The trace can be saved as a .ruletrace package and opened in irAuthor, or read as trace frames/events through the SDK.

note

Tracing is resource-intensive and is not intended for production use. Reserve it for validation and troubleshooting.

• Rule Tracing: Overview
• Rule Tracing Concepts (Trace Frame, Aspect, Trace Events / Evaluations)

2. Execution Log Options (Read Back Through the SDK)

The EngineLogOptions flag enumeration controls what the engine records on the RuleExecutionLog. The flags most relevant to capturing values are:

• RuleValues: captures rule values so they can be read back through the SDK. (Adds memory consumption and reduces performance. When off, accessing certain rule values or execution counts from the SDK raises an IntegrationException.)
• StateChanges (the EngineLogOptions.Changes enum member): captures state changes, including the values produced by calculations.
• Execution: adds RuleSet, Rule, and Action execution messages for context on what fired.

Flags can be combined (for example, EngineLogOptions.Execution | EngineLogOptions.Changes). The RuleExecutionLog is returned from RuleSession.ApplyRules() and Entity.ExecuteRuleSet(), and is also available from RuleSession.LastRuleExecutionLog. To receive the log automatically after each execution, implement IRuleExecutionLogSink.

note

Iterating RuleExecutionLog.AllMessages yields human-readable text messages, not a structured per-field value map. For values keyed to specific elements, use the RuleValues data accessed through the SDK, or parse the Rule Trace evaluations described above.

• Rule Engine Execution Log (EngineLogOptions reference)
• Execution Log in irSDK (IRuleExecutionLogSink)
• Executing Rules: Retrieving and Processing the RuleExecutionLog

3. Notifications and Metrics (Production-Friendly)

When tracing is too heavy for a running environment, you can emit the specific values you care about. A Fire Notification action's message can embed field and expression values (for example, <%ItemQuantity%>), and associating a field with the notification causes the field's element-id to be returned at runtime. Notifications are read from irVerify or via the SDK. For structured numeric/operational output, metrics logging can be enabled by assigning an IMetricLogger implementation to RuleSession.Settings.MetricLogger.

The trade-off is that this approach is author-driven: you choose which values to emit, rather than capturing everything automatically.

• Actions: Fire Notification (embedded fields, associated field / element-id)
• Executing Rules: Checking for Notifications & Validations
• Executing Rules: enabling metrics logging

Collections and Multiple-Member Entities

Traced activities are identified by an ElementIdentifier that includes the entity member (for example, {Entity1::1}/Entity1/Calc1), so values evaluated for individual members of a collection are distinguishable from those of a single-member entity. For loading and reading collection state through the SDK, see Working with Collections.