The point that a post-hoc auditor sees only legal, correct data is the part I'd want to act on, and section 7 hints at the fix. If each skill stored its precondition as structured fields (repo, language, tool, task type) and the extractor was only allowed to widen scope when experiences from independent sources and distinct contexts agreed, the "add a lock to everything" generalization gets harder to induce. A cheap runtime complement is a counterfactual check: before a distilled skill is promoted, replay a few held-out tasks with and without it, and quarantine any skill that moves accuracy a lot in one direction. Combined with the per-source experience cap you mention, that also catches the low-and-slow variant the paper doesn't attempt. Have you seen anything on how provenance tags could be kept attached to a skill after several rounds of merging?