outlist-semantics-are-fully-specified

IN derived (depth 1)

The outlist primitive has complete, well-defined semantics: multiple entries form a conjunction (all must be OUT), absent nodes are treated as OUT (permissive default), and outlist relationships survive persistence through JSON serialization with rebuilt dependent indexes.

Summary

The rules for how "outlist" conditions work are completely nailed down with no ambiguity. When a conclusion depends on certain things being absent or false, all of those things must actually be absent for the conclusion to hold, anything not yet in the system counts as absent by default, and these relationships are correctly saved and restored from the database without losing their behavior.

Justifications

SL — These three beliefs specify the complete behavioral contract of the outlist primitive — conjunction, absence handling, and persistence — independent of how it is used

Antecedents (all must be IN):

  • multiple-outlist-is-conjunction — When a justification has multiple outlist entries, ALL must be OUT for the justification to be valid; any single outlist node going IN defeats the entire justification
  • outlist-absent-means-out — An outlist node that doesn't exist in the network is treated as OUT (justification satisfied); absent antecedent nodes fail validation — this asymmetry makes missing counter-evidence permissive while missing supporting evidence is strict
  • outlist-relationships-survive-persistence — Outlists are stored as `outlist_json` in the SQLite `justifications` table; on load, the dependent index is rebuilt for both antecedents and outlist nodes, preserving propagation behavior across save/load cycles

Dependents

These beliefs depend on this one:

Details