staleness-is-conservative-ci-gate
IN derived (depth 1)
Staleness checking is designed as a safe CI gate: it never mutates state, only checks IN nodes, requires both source fields, and exits nonzero to fail the pipeline
Summary
The staleness checker is intentionally designed to be safe for automated pipelines. It only reads data without changing anything, only looks at active nodes, requires complete source information before flagging anything, and signals failure through its exit code so CI systems can block on it. This makes it a conservative gate that avoids false positives from incomplete data or already-retracted nodes.
Justifications
SL — All four properties are necessary for CI safety — mutation would be dangerous, checking OUT nodes wasteful, missing fields a false positive, and zero-exit a silent pass
Antecedents (all must be IN):
- check-stale-is-read-only — `check_stale` never mutates the network; it returns a list of stale-node dicts and leaves all nodes unchanged — staleness detection is separated from staleness resolution.
- check-stale-exits-nonzero — `cmd_check_stale` calls `sys.exit(1)` when any stale nodes are found, making it usable as a CI or pre-commit gate.
- check-stale-skips-out-nodes — Only nodes with `truth_value == "IN"` are checked for staleness; retracted (OUT) nodes are ignored even if their source file has changed.
- check-stale-requires-both-source-fields — A node must have both `source` (non-empty) and `source_hash` (non-empty) to be eligible for staleness checking; nodes missing either field are silently skipped.
Dependents
These beliefs depend on this one:
- all-belief-inspection-is-non-mutating-and-fault-tolerant — All belief inspection operations — quality review (read-only with fault-tolerant batch handling), staleness checking (conservative non-mutating CI gate), and negative classification (defensively bounded with graceful degradation) — are uniformly non-mutating and fault-tolerant, ensuring observation never perturbs the observed system.
- data-integrity-spans-architecture — Data integrity is enforced across all three architectural layers: clean layer boundaries prevent cross-cutting mutations, snapshot persistence ensures atomic state transitions, and conservative staleness checking gates CI pipelines.
- dual-quality-gates-are-complementary-and-non-mutating — The system enforces belief quality through dual non-mutating gates targeting complementary validity dimensions: review validates logical soundness of derived beliefs (scoped to justified nodes, dry-run gated auto-retraction), while staleness checking validates source currency of all IN beliefs (conservative CI gate with nonzero exit on drift) — neither gate can corrupt network state.
- external-belief-lifecycle-is-complete — The system manages external beliefs across their full lifecycle: import/sync provides dual reconciliation modes with heterogeneous truth state handling and namespace auto-wiring, while staleness checking detects source drift for CI gating — beliefs are tracked from initial ingestion through ongoing validity monitoring.
- 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.
- staleness-gate-catches-all-drift — The staleness CI gate detects all forms of source material drift without false negatives.
- staleness-output-is-ci-pipeline-ready — Staleness checking produces deterministic, uniformly-structured, machine-parseable output with conservative non-mutating semantics and nonzero exit codes, making it directly consumable by automated CI pipelines without wrapper scripts