Files
evil_MoE/.claude/memory/feedback_rename_on_logic_change.md
T
wassname bcf09dd742 docs
2026-06-06 12:27:26 +00:00

1.3 KiB

name, description, metadata
name description metadata
feedback_rename_on_logic_change when you change a method's logic, rename the arm/intervention id -- don't reuse the old name
node_type type originSessionId
memory feedback 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.