premise-behavior-emerges-from-absence

IN derived (depth 1)

Premise behavior is not explicitly implemented — it emerges from three defaults: nodes with no justifications default to IN, empty antecedent lists are vacuously valid, and the system preserves a premise's current truth value rather than deriving it.

Summary

The system never has special "this is a premise" code — instead, premises work because three independent defaults happen to combine correctly. A node with no justifications stays IN by default, an empty antecedent list counts as satisfied, and the system preserves existing truth values rather than recalculating them. This matters because it means premise behavior is an emergent property of the architecture, not a designed feature, which makes it fragile if any of those three defaults change independently.

Justifications

SL — The "premise" concept requires no special case in the engine — it falls out of the general evaluation rules applied to empty structures

Antecedents (all must be IN):

  • premises-have-no-justifications — A premise node is represented by an empty `justifications` list and defaults to `truth_value="IN"`; the system treats the empty-justifications case as a special unconditional belief.
  • premise-defaults-to-in — A node with no justifications (a premise) defaults to IN; `_compute_truth` preserves its current truth value rather than recomputing it.
  • empty-antecedents-vacuously-valid — An SL justification with an empty antecedent list is valid (vacuous truth via `all([])`), allowing outlist-only justifications to function as "IN unless Y" — used by `challenge` and `supersede` for converted premises

Dependents

These beliefs depend on this one:

Details