Decision Tables
A decision table is a grid view of a rule set: each rule is a row, its condition clauses are input columns, and the values it writes are output columns. It is the fastest way to author and read a set of “when these inputs, set these outputs” rules.
The grid
The decision table and the rule list are two views of the same rules — the table just lays them out as a grid so a whole family of decisions reads at a glance. Reach it from the rule set editor.
| Grid part | Is |
|---|---|
| Row | One rule. |
| Input columns | The rule's condition clauses — the tests that decide whether the row matches. |
| Output columns | The context keys the row sets when it matches, edited cell by cell. |
The execution toolbar sits above the grid (and above the List view). Its badge shows the rule set's match policy — including Inference when forward chaining is on. In Inference mode each row can carry a per-rule salience, edited in the row's settings overlay (the gear); a nonzero salience shows a small badge on the row, for example S5.
An input cell's popover does more than set a value: when the clause's value is an array it also offers the Aggregate and Quantifier modifiers — the same ones available in the full clause editor.
Per-row settings
The gear on a row opens its settings overlay, which holds the per-rule options that are not part of the grid itself: action randomization, action sequence, salience, and the rule's active dates — an effective date, an expiration date, or both. Each date has a companion time field and a clear button; leave a date blank for “always active” or “never expires”. Enter them in your own time zone; they are stored as UTC. The overlay flags an expiration that is not later than the effective date before you try to save.
A row with a date limit worth flagging shows a small calendar icon next to the rule name, in one style while the rule is live and a dimmed one while it is still scheduled or already expired. Hover it for the exact dates. A row can also be switched off entirely with its Enabled checkbox (also on the row menu), which skips the rule regardless of dates.
Rows the table is missing
A decision table invites the question “have I handled every case?”, and the Verify tab answers it. After a check, every combination of inputs that no rule matches also appears in the grid as a Not covered row, laid out under the columns it constrains, with a “N not covered” count in the toolbar above the grid. A column the region says nothing about is left blank, which reads as “any value”.
The rows are shown where they would sit rather than only listed elsewhere, because a coverage gap is a row that is not there — nothing highlighted in an existing row can show it. They are markers, not rules: add a real row to fill the gap, or leave it if that combination genuinely needs no outcome. The toolbar also carries the table's own advisory count of duplicate and shadowed rows among the rules it can decompose.
Output columns and the managed action
Behind the scenes, every output column in a row is written by a single table-owned action named Decision outputs. This managed output action is created, updated, and cleaned up by the table itself: adding an output column, editing a cell, or renaming a column all edit that one action, and when a row has no outputs left the action is removed. You never manage it by hand — you just fill in cells.
Any action you add to a rule yourself — including your own action that writes to the context — is never absorbed, reordered, or rewritten by the table. It stays an ordinary action in the rule's sequence and keeps its position. The table only owns the Decision outputs action.
When a value is ambiguous
Because actions run in order and, in a single-pass run, the last write to a context key wins, the table warns you when one of your actions writes to a key that is also an output column. The affected cell is flagged, since the value that actually ends up in the context depends on where your action falls in the sequence relative to the managed output action. Resolve it by removing the overlap or by ordering the actions deliberately. Under Inference the same key may be rewritten across several firings as rules re-fire; the run trace shows each change in order.
Rows driven by a shared action set
A rule can run a named, shared action set instead of inline actions (see Rules). Those rows do not have editable output cells — the table shows that their outputs are managed by the action set, because the values come from the shared logic rather than from the grid. Edit the action set to change what such a row produces.