lifecycle-management-is-gapless

IN derived (depth 3)

The system manages belief lifecycle without gaps across all operation types: staleness checking detects all forms of source drift, propagation respects node lifecycle states, and both read and write paths enforce consistent lifecycle semantics — no operation ignores or corrupts lifecycle state.

Summary

Every operation in the system — whether it's checking for stale data, propagating changes, reading, or writing — consistently respects and preserves the lifecycle state of each node. Nothing slips through the cracks: staleness detection catches all forms of source drift, and no operation accidentally ignores or corrupts whether a node is active or retracted. This means the system's picture of what's current and what's been withdrawn stays accurate and complete at all times.

Justifications

SL — drift detection + lifecycle-aware propagation = complete lifecycle management (depth-3 GATE from two depth-2)

Antecedents (all must be IN):

  • staleness-gate-catches-all-drift — The staleness CI gate detects all forms of source material drift without false negatives.
  • lifecycle-awareness-spans-checking-and-propagation — Both read-only inspection and mutation-driven propagation respect node lifecycle consistently: staleness checking skips OUT nodes and never mutates state, while propagation skips retracted nodes and preserves trigger identity — lifecycle state is honored across the system regardless of whether the operation is read or write.

Unless (any of these IN defeats this justification):

  • missing-source-file-is-silent — If a node's source file no longer exists on disk, `check_stale` silently skips it; callers cannot distinguish "file deleted" from "file never tracked."
  • hash-truncation-is-16-hex — Source hashes are SHA-256 truncated to the first 16 hex characters (64 bits), reducing collision resistance to ~32 bits for birthday attacks compared to the full 256-bit hash.

Dependents

These beliefs depend on this one:

Details