survey_version_question_visibility_conditions

Overview

The conditions belonging to a visibility rule. The column layout is identical to branch conditions.

Logical name	Physical name	Column	Type	PK	Relation	Nullable	Default	Notes
Visibility condition	survey_version_question_visibility_conditions	id	uuid	◯			gen_random_uuid()
		visibility_rule_id	uuid		survey_version_question_visibility_rules:id (cascade)
		source_question_code	varchar(100)					Source question code. intro questions cannot be used
		operator	branch_operator					Condition operator. Shares the enum with branch conditions
		comparison_value	text					Comparison value: choice label / matrix row label / FA matching text
		sub_comparison_value	text			◯		Matrix column label / FA target field label. null = any field
		sub_question_index	integer			◯		Sub-question index for SA / MA. null = treat all sub-questions flatly
		sort_order	integer					Position within the rule
		created_at	timestamptz				now()

visibility_rule_id → survey_version_question_visibility_rules.id (onDelete: cascade)

Primary key (id)
UNIQUE INDEX: visibility_conditions_rule_order_idx (visibility_rule_id, sort_order)

The same branch_operator enum as branch conditions, with the same semantics.

Value	UI label
`equals`	equals
`includes`	includes
`not_includes`	does not include (also holds when unanswered)
`only`	is only
`not_only`	is not only (also holds when unanswered)
`has_other`	has other than
`answered`	answered

Why the tables are separate: even though the condition shape is identical, the parent rules produce different outputs (a destination versus hide targets), so they are normalized as separate systems. CS likewise keeps logic_items and visibility_items as separate tables
Why the enum is shared: the condition semantics are exactly the same, which prevents an operator change from being applied to only one of the two
Real CS traffic confirms that visibility_items has the same shape as logic_items (verb / answer_item_id / sub_item_id / value / score_group_id)