An unassigned input is not FALSE: incomplete assignments

An input with no value is not FALSE. Evaluating A AND B with A = TRUE and B unassigned gives no value, and the engine says which input is missing rather than guessing.

The evaluation below assigns A = TRUE and leaves B out. The result is reported as incomplete, with B listed as the input without a value, and no output value is given. A tool that defaulted B to FALSE would have returned FALSE and looked finished; a tool that defaulted it to TRUE would have returned TRUE. Both would have been inventing data.

The engine does not short-circuit its way to an answer either. FALSE AND B could be decided without B, and some evaluators would say so; the engine's rule is that a complete assignment is required before any value is reported, so that the result of a rule never depends on which inputs happened to be filled in first. Checks run over complete assignments only, which is what makes a truth table a table.

The pattern matters in forms and APIs: an unchecked box, a missing field and a NULL column are all “no value”, and treating them as FALSE is a decision the rule should make explicitly, with an input like consent_given whose absence is a FALSE by definition, not by accident. The SQL pitfall on NULL is the same point in a different language.

Incomplete evaluation

A AND B with A = TRUE and B unassigned: result no value (incomplete assignment); inputs without a value: B.

The common slip

Assuming that an input nobody set is FALSE. In the model it has no value; in a form it may mean “not asked”; in a database it is NULL. Make the default a stated rule, and the engine's incomplete-assignment report stops appearing for the right reason.

Questions

Does the engine ever evaluate with a partial assignment?

It reports the evaluation as incomplete and names the missing inputs; it does not produce an output value. The Python export behaves the same way and raises an error for a missing input.

How do I model an optional input?

With two inputs, one saying whether the value is known and one giving the value, for example banned_known AND NOT banned. Every combination is then a complete row and the checks cover it.

Related

Tools

• Logical equivalence checker: two expressions, exact verdict, counterexample
• Truth table generator: any Boolean expression, up to 12 variables, with intermediate columns

See also

• NULL is not FALSE: three-valued logic in SQL
• Boolean logic in Python: and, or, not, precedence and common mistakes
• NOT gate (inverter): truth table, symbol and the NOT operator
• Is 1 true or false? 1 = TRUE, 0 = FALSE in Boolean logic
• Truth table: meaning and examples
• A review checklist for decision rules (for analysts and reviewers)

Pitfalls

• XOR of three inputs is odd parity, not “exactly one”
• A → B does not give B → A
• Necessary vs sufficient: “only if” is not “if”
• Inclusive vs exclusive or (OR vs XOR), with truth table

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.