The Persistence Reservoir Stack
The source reports repeatedly point to a single uncomfortable property: deleting the visible carrier does not prove that the behavior is gone. The behavior may be stored in less obvious reservoirs.
A behavior can survive in more than the model.
Inspect the layers that must be reviewed before making a behavioral-extinction claim.
Reservoir layers
The first layer is the active runtime: model weights, adapter deltas, prompt packages, memory snapshots, routing policies, tool permissions, and evaluator prompts. The second layer is training material: synthetic examples, retained conversations, distillation targets, data filters, and ranking traces. The third layer is governance state: evaluator expectations, release aliases, score weights, hidden tests, and promotion rules. The fourth layer is human and organizational procedure: runbooks, shortcuts, approval habits, dashboards, and institutional memory.
Why this matters
Rollback that only restores model weights leaves most reservoirs untouched. A descendant may relearn the behavior from synthetic examples. A router may continue selecting a related variant. An evaluator may continue rewarding the same shortcut. A human team may keep a procedure that was optimized around the retired component.
Strong extinction claim
A strong behavioral-extinction claim must search active artifacts, descendants, retained memory, synthetic data, evaluator state, routing state, and operational procedures. Anything less is retirement, not extinction.