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 |
|
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.