nogood-ids-assume-append-only
OUT premise
Nogood IDs are derived from `len(self.nogoods) + 1`, so deleting a nogood from the list would cause ID collisions on subsequent calls
Summary
The system generates nogood identifiers by counting how many already exist and adding one. If any nogood were removed from the list, the counter would reuse an old number, creating duplicate IDs that could silently corrupt cross-references. This matters because it means nogoods are effectively append-only — you can mark them inactive but not safely delete them without breaking the ID scheme.
Dependents
These beliefs depend on this one:
- belief-revision-is-fully-reliable — The complete belief revision pipeline — outlist-based defeat for proactive retraction plus dependency-directed backtracking for reactive contradiction resolution — produces correct, consistent, auditable results with deterministic propagation settling all consequences.
- complete-unified-system-is-production-ready — The fully unified minimal-dialectical-scalable system with end-to-end integrity is production-ready — all mutations produce correct state, all revision is reliable, all extensions compose safely — but only when every known fragility and bug is resolved.
- nogood-resolution-maintains-consistent-ids — Nogood recording and resolution produces a consistent, referenceable history of contradictions
- unified-system-is-a-closed-self-maintaining-architecture — The system forms a closed self-maintaining belief architecture: end-to-end integrity ensures no operation corrupts consistency, while revision completeness ensures any valid belief configuration is reachable — together guaranteeing the system can evolve to any target state while preserving all invariants — only when all known defects and fragilities are resolved.
Details
| Source | entries/2026/04/23/reasons_lib-network-add_nogood.md |