Rule expressions

Rule expressions are boolean conditions and text templates attached to an entity definition. They cover four surface families, each with its own page, all sharing the expression language described in Syntax and types and one validation endpoint.

Expression surfaces

Surface	What it does
Field behavior conditions	VisibleWhen, RequiredWhen, and EditableWhen expressions on entity fields, evaluated per operation mode.
Declarative logic	Mutation-effect ApplyWhen conditions evaluated before the effect source and fallback selection.
Presentation rules	Templates and conditions that compute a record’s display name and subtitle.
Statements	Named boolean facts compiled to PostgreSQL for server-side filtering and runtime predicate payloads.

Validation rules share the same language but are managed and validated through their own endpoints; see Validation rule expressions.

Shared validation endpoint

These surfaces are checked by the same operation before saving:

POST /api/workspace/admin/entity-definitions/{entityDefinitionId}/rule-expressions/validate

The request selects the context with ContextType (FieldBehavior, MutationEffect, Presentation, or Statement) and the language variant with ExpressionType (Condition for boolean expressions, Template for presentation text templates). The expression itself is sent as Value; field behavior expressions also pass EntityDefinitionTableId to name the table whose field schema applies.

Mutation-effect validation uses ContextType: MutationEffect and ExpressionType: Condition. The expression is bound to the primary table and may use primary scalar fields, Operation.Mode, and one direct Reference hop. The endpoint also enforces the mutation-effect limits: 8 KiB UTF-8, 256 AST nodes, boolean depth 32, and at most 16 distinct paths.

The check saves nothing and returns IsValid plus structured errors: each error carries a message, the offending token and resolved field path when available, and a stable code. The endpoint is part of the Configuration API.