Visual Decision Rules

Some decisions do not belong inside a workflow step. Who gets approved automatically, what goes to a human reviewer, which cases are declined outright - that logic is reviewed by people who do not read code, changes more often than the process around it, and has to be explainable after the fact. Burying it in a chain of nested conditions on a canvas makes it hard to read and harder to audit.

This concept separates that logic into its own object: a named rule set with its own version history and its own active state, edited as a decision tree. The illustration shows a lending decision as the example. A palette on the left offers the building blocks - a single condition, complex logic that combines conditions with AND and OR, a scoring rule that calculates a value, a decision that defines an outcome or action, and a lookup that fetches data from a source - with a drop area for dragging new blocks onto the canvas.

The tree itself reads top to bottom. A root condition tests a credit score against a threshold and splits, with the comparison written on each edge so the path is legible without opening anything. One side evaluates a debt-to-income condition, calculating a risk score on its passing branch and sending the other straight to review; the other side calculates a risk score at once and branches on the resulting value. Four terminal outcomes close the tree, visually distinguished by kind: an automatic approval, two routes to manual review by an analyst, and an automatic decline.

The right panel is what makes the tree trustworthy. Sample inputs are entered as ordinary numeric fields, a derived field is computed and shown read-only, and a single action evaluates the rule set against them. The result card names the outcome and the score that produced it, reports how long the evaluation took, and links to a trace of the evaluation, so an author can show exactly which branches fired for a given case. A header status marks the rule set as active with a version selector, an export action and a save control, and a resource meter sits in the sidebar.

The design places the rule-set editor inside the workflows area of the product, with the same canvas controls, minimap and versioning cues as the builder. The intent is to keep decision logic readable and testable by the people who own it, while the workflow canvas stays free of deeply nested branching.