outlist-absent-means-out
IN premise
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
Summary
When checking whether counter-evidence exists, the system gives the benefit of the doubt: if the counter-evidence node was never even created, it treats that as "no counter-evidence found" and lets the belief stand. But for supporting evidence, the opposite applies — if a required supporting node is missing, the belief fails. This design means you don't have to explicitly create and mark every possible objection as false; silence counts as absence of objection. It also means beliefs can't accidentally survive on phantom support that was never actually established.
Dependents
These beliefs depend on this one:
- missing-nodes-have-asymmetric-fail-semantics — Missing nodes are treated asymmetrically: absent antecedents fail validation (conservative), absent outlist nodes pass (permissive), creating a "believe unless proven otherwise" default
- outlist-semantics-are-fully-specified — 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.
Details
| Source | entries/2026/04/23/topic-outlist-semantics.md |