nogood-ids-are-durable-and-collision-free
IN derived (depth 1)
Nogood IDs form a durable collision-free sequence: the counter only increases (surviving deletions and clears), persists across save/load cycles via the network_meta table, and advances past imported IDs to prevent collisions — no operation can produce a reused or ambiguous contradiction identifier
Summary
Each nogood (recorded contradiction) gets a unique numeric ID that will never be reused or collide with another, because the counter only goes up, is saved to disk between sessions, and automatically jumps past any imported IDs. This means contradiction records can be reliably referenced by ID across time, across save/load cycles, and even after merging data from other systems.
Justifications
SL — Three independent ID management properties — monotonicity, persistence, and import-aware advancement — combine into a single durability guarantee that ID-based contradiction references never become ambiguous
Antecedents (all must be IN):
- nogood-id-counter-is-monotonic — `Network._next_nogood_id` only ever increases — deletion, clearing, save/load, and import never decrease it, preventing ID reuse after the issue #26 fix
- nogood-id-persisted-in-meta — The nogood counter is stored in the `network_meta` SQLite table and survives save/load cycles as a high-water mark, not a count of current nogoods
- nogood-id-collision-prevention — After importing nogoods, `_next_nogood_id` is set to one past the highest imported ID, preventing `network.record_nogood` from generating a conflicting ID later.
Dependents
These beliefs depend on this one:
- all-identifiers-are-durable-across-persistence-boundaries — All system-generated identifiers are not only deterministic and collision-free at creation time but also durable across persistence boundaries — nogood IDs survive save/load cycles via the network_meta table's high-water mark, ensuring the collision-free property is maintained across the system's entire operational lifetime rather than just within a single session