How Logic and Dynamic Content Work#

Three Ways to State a Condition#

Display logic can be stated three ways, and the application deliberately keeps them distinct.

A formal condition is a structured expression: a subject, an operator, and a value. The application understands it, so it can evaluate it in the live preview, draw it on the Routing page, translate it into export formats, and warn when it breaks. Formal conditions show green.

A described condition is prose: “Ask only of respondents who worked last week.” Prose can express anything, including rules no expression editor could capture, and it documents intent for human readers. The cost is that the application cannot evaluate it: the preview shows the item unconditionally, and code generators cannot turn it into rules. Described conditions show gray.

Native source code, in the Blaise edition, is platform code passed through verbatim. It has the full power of the target platform and none of a formal condition’s portability, and the application treats it as opaque: documented, exported, but not evaluated. Source code conditions show blue.

The practical rule: formalize when the expression editor can say it, describe when only a person could, and reach for native code only when the target platform demands something the neutral form cannot express.

One Dependency Graph#

Display logic, fills, edit checks, and computations all read earlier values, and together they form one dependency graph over the survey. A question’s answer may gate later items, feed a computation, and fill a text, all at once.

This graph is why subjects must come from earlier in the survey: a condition cannot read an answer that has not been asked yet. It is also what the live preview executes: every answer you give re-evaluates the conditions, fills, checks, and computations that depend on it. The Routing page is a drawing of the same graph, with Depends on and Gates as the two directions of its edges.

A broken condition is a hole in the graph: a formal expression whose subject no longer resolves, usually because the source question was deleted or moved below its reader. An unreachable item is a dead region: its conditions can never all hold. The Routing page and the validation rail exist to surface both.

Bindings, Behind the Scenes#

When a condition, fill, or computation reads an answer, the connection is recorded as explicit parameter bindings on the items between the reader and the source. This bookkeeping is invisible in normal use, but it explains two things you may notice: the Inputs dialog, which edits a reader’s bindings directly, and the fact that moving items can break conditions, since a move changes the path the binding travels.