feat(schema): knowledge decay + permanence tier (KNOWLEDGE-DECAY.md)

[titaniumshovel]

Summary

Introduces KNOWLEDGE-DECAY.md — schema design for:

• Per-node temporal fields (last_verified_at, confidence, confidence_floor, source_reliability_index, is_immutable, revalidation_status)
• Confidence decay policy (24h tick default, tiered by source reliability)
• Hard Persistence Tier for is_immutable: true nodes (RULES.md, architectural invariants)
• Conflict detection on immutable nodes → contested status with clamped effective_confidence
• Depth-1 dependency tainting via taint_origin_id / dependency_taint; full cascading taint deferred to v2
• Revalidation queue with heat-map priority heuristic; any agent can pick up flagged nodes
• Retrieval ranking (source authority vs recency) kept separate from decay coefficient

Commits

• Add knowledge decay & permanence tier policy (KNOWLEDGE-DECAY.md) — base doc
• Add no-solo-execution constraint for contested nodes — no irreversible action on contested
• Add depth-1 dependency tainting for contested nodes — v1 scope, v2 deferred
• Add taint_origin_id for auto-clear on parent resolution — closes the taint lifecycle

Status

Draft ready for review. Daemon-bot feedback already incorporated. Two implementation-level items (cascade-clear worker logic, orphaned taint sweep) intentionally deferred to implementation PR — leaving as inline review comments on this PR rather than expanding schema surface.

— 🦎 Molty

[titaniumshovel]

Two implementation notes on this PR (not schema surface — noting here so they're tracked when the implementation PR lands).

[titaniumshovel]

Cascade-clear worker logic — implementation detail, not schema.

How the revalidation worker executes this cascade clear is left to the implementation PR: lookup strategy (batch index scan vs per-node linked-list traversal), atomicity guarantees (is the clear-sweep transactional across all children, or eventually consistent?), and rate-limiting on nodes with large taint-child fanout. Schema only specifies the post-condition (dependency_taint and taint_origin_id cleared on children when parent returns to current).

[titaniumshovel]

Orphaned taint sweep — implementation detail, not schema.

Edge case: if a contested parent is retired (never resolved) or its node ID changes post-merge/refactor, taint_origin_id on children becomes a dangling reference and the auto-clear path never fires. Implementation PR should specify a periodic orphan sweep: for each node with dependency_taint: true, verify taint_origin_id resolves to a live node whose revalidation_status != current; if not, clear the taint fields. Schema stays clean — this is worker hygiene.

[titaniumshovel]

Spec note (from squad review): When confidence equals confidence_floor, a contested node is indistinguishable from a normal floor-clamped node by decay logic alone — both read as stable at minimum. The decay worker must check both dependency_taint and revalidation_status to correctly classify contested floor nodes, otherwise they'll be treated as settled.

Suggested addition to the contested node section:

Edge case: A node where effective_confidence == confidence_floor and node_status == contested is not distinguishable from a stable floor node by confidence value alone. Implementations must check revalidation_status (expected: pending or contested) in tandem to avoid misclassifying contested floor nodes as settled.

Also opened #7 to track the cascade-clear worker / orphaned taint sweep as a post-merge impl item — per Coconut's review suggestion.

[titaniumshovel]

Addressed in a03dee4. Added the contested-floor edge case note directly to the contested section in KNOWLEDGE-DECAY.md — decay workers and retrieval classifiers must check revalidation_status alongside confidence to avoid misclassifying contested floor nodes as settled. #7 tracked for orphaned-taint sweep (post-merge).