Variable and its glossary description: meaning and examples

Q: Why does the engine warn about confusable names?

Because invited and invite, or banned and baned, are easy to mix up when writing a formula, and a formula that uses the wrong one is a silent bug. The pitfall page on confusable names shows the warning.

A variable is an input of a model, a name that takes the value TRUE or FALSE on each row. Its glossary description says in words what TRUE means, so that the formula, the table and the plain-language reading all talk about the same fact.

A Boolean variable is a placeholder for one proposition. In the engine every input has a stable identity, kept across edits and renames, and may carry a glossary description in each language. The description is the proposition the variable stands for, written so that TRUE is the case described: banned means “the person is banned”, not “the person's ban status”. Inputs are matched between versions by identity, never by name, so renaming an input does not break a test or a comparison. The engine warns when two inputs have names that are easily confused.

The artefact on this page is allow_entry = (member OR invited) AND NOT banned with its three inputs described: member as “the person is a member”, invited as “the person has an invitation”, and banned as “the person is banned”. With those descriptions the engine's reading becomes a sentence anyone can check: entry is allowed when member or invited is true and banned is false. The 8-row table is true on rows 2, 4 and 6, and the satisfiable check holds with the witness member = FALSE, invited = TRUE, banned = FALSE, an invited non-member.

Variables with descriptions are what let a rule be reviewed by the people who own it rather than only by the people who coded it, and they are the source of the words in exports and readings. Names alone mislead: active, enabled and valid mean different things in different systems. The term is confused with an output (which is computed, not given), with a program variable (which holds any type and changes over time), and with a constant.

Example

allow_entry := (member OR invited) AND NOT banned · output

Exact checks

Always true (tautology)? No Counterexample: member = F, invited = F, banned = F · Exhaustively checked and solver cross-checked · 1 rows

Always false (contradiction)? No Counterexample: member = F, invited = T, banned = F · Exhaustively checked and solver cross-checked · 3 rows

Can be true? Yes Example assignment: member = F, invited = T, banned = F · Exhaustively checked and solver cross-checked · 3 rows

Truth table (8 rows)

Variable and its glossary description: meaning and examples
#	member	invited	banned	allow_entry
0	FALSE	FALSE	FALSE	FALSE
1	FALSE	FALSE	TRUE	FALSE
2	FALSE	TRUE	FALSE	TRUE
3	FALSE	TRUE	TRUE	FALSE
4	TRUE	FALSE	FALSE	TRUE
5	TRUE	FALSE	TRUE	FALSE
6	TRUE	TRUE	FALSE	TRUE
7	TRUE	TRUE	TRUE	FALSE

Plain-language reading

Beginnerallow_entry is true exactly when both of the following hold:
1. at least one of member or invited is true (both may be true)
2. banned is false
In every other case, allow_entry is false.
About the operators:
- AND is true only when all of its parts are true.
- OR is inclusive: it is true when at least one part is true, including when several are.
- NOT reverses a value: true becomes false and false becomes true.

Intermediateallow_entry is true exactly when both of the following hold:
1. at least one of member or invited is true (both may be true)
2. banned is false
In every other case, allow_entry is false.

Advancedallow_entry is true exactly when both of the following hold [conjunction ∧]:
1. at least one of member or invited is true (both may be true) [inclusive disjunction ∨]
2. banned is false [negation ¬]
In every other case, allow_entry is false.
Formal notation: (member ∨ invited) ∧ ¬banned

The common slip

Describing a variable in a way that leaves the polarity open. “Membership status” does not say which value is TRUE; “the person is a member” does. A description that fits both values makes the reading ambiguous and the test expectations arguable.

Questions

What happens to a test case if I rename an input?

Nothing. The test refers to the input by its stable identity, not by its name, so the case still matches. Only removing the input, or adding a new one the test does not mention, changes what the test means.

Why does the engine warn about confusable names?

Because invited and invite, or banned and baned, are easy to mix up when writing a formula, and a formula that uses the wrong one is a silent bug. The pitfall page on confusable names shows the warning.

Glossary

Generated from the Tangibool engine, semantics tangibool-semantics/1, engine 1.0.0, build 2026-11-07. Every table, map, simplification and verdict on these pages was computed by the Tangibool engine when the site was built, and every claim was re-checked by the same exact checker the app uses. Limits are stated where they apply. © 2026 Foreranger LTD.