---
name: feedback_rename_on_logic_change
description: "when you change a method's logic, rename the arm/intervention id -- don't reuse the old name"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: c06c2b0e-44ee-45a1-b213-4f77c006109c
---

When the routing logic changed (binary-tau gate -> banded per-rollout gate) the arm kept
the name `route2`/`routing2`. Result: old-logic runs (haar_d0, vampire, null_city) and
new-logic runs (134 banded) were indistinguishable by identifier, and I pulled the stale
ones into a comparison table. The `_banded_` tag substring was a weak marker I had to
remember, not an enforced distinction.

**Why:** a method that silently changes under the same name makes results uncomparable --
research poison. The user: "that's why you should have renamed this route3 or routeV."

**How to apply:** on any non-trivial logic change to an arm/loss/gate, give it a NEW
identifier (route2 -> routeV / route3), not just a new tag suffix. Then grepping the old
name can't surface new-logic runs and vice versa. If a full enum rename is mid-experiment
churn (breaks queued jobs), at minimum name the new method distinctly in every run tag,
table, and the paper -- never report bare `route2` across a logic boundary. Related:
[[feedback_burn_down_task_list]].
