Proposal: `orx exp move` (re-parent) and `orx exp delete/archive` — light pruning for experiment trees

[tizerluo]

Hi folks — I took OpenResearch for a full spin tonight (a real research campaign: a cross-tier model comparison study with ~15 nodes and real runs on a local backend) and the experiment-tree model held up beautifully. One structural gap surfaced, though, and it's the only thing that hurt.

What happened

Following the "vary config, not the command" rule, I branched a set of cross-model replications as children of the experiment node whose protocol they inherit (same 74-prompt run command, only config.json differs per branch — model + lens paths). Semantically these four nodes form a comparison grid, not variants of that one 2B experiment, so the natural home for them was a dedicated second baseline root. That's when I found:

1. No re-parent. orx exp has status/run/cancel/wait/wake/desc; the dashboard protocol-2 API has no PATCH on parentExperimentId (/api/experiments/:id → route not found), and the dashboard has no affordance for it either. The only path was to recreate the four nodes under a new --baseline root and re-run all four experiments so they'd carry honest run records. That was cheap for us (~20–40s per readout run), but for anything with multi-hour runs this workaround is prohibitive — the run history is stranded on the old nodes.
2. No delete/archive. The replaced nodes can't be removed: no CLI command, no API route, no dashboard action. They now linger under the old parent as tombstones with a "migrated, see family-grid subtree" note in their description. The tree view will show them forever.

Concrete asks

orx exp move <expId> --parent <newParentId>   # or --baseline to make it a new root
orx exp delete <expId>                        # refuse while runs exist, --force to override; flag for branch handling
orx exp archive <expId>                       # softer alternative: hide from default tree view, keep runs/evidence

Notes on semantics that might make this easy:

• move only touches tree linkage in the store — git branches can stay exactly where they are. Branch parentage already diverges from node parentage the moment you create a child, so there's no git-side consistency to maintain.
• archive alone would solve 80% of the tombstone problem for us.

Why it matters

Research is a DAG (question lineage × comparison grids), and the tree + multiple-baselines design is a good projection of it. But trees grow organically: nodes end up under the wrong root, or a restructuring reveals that a subtree is really its own family. Light pruning is what keeps a long-lived project legible in the dashboard six months in. Right now the model is append-only in practice.

Happy to test any of this on our (now two-rooted, slightly haunted) project tree 🙂

[AbarnaaSree]

I'd like to work on this issue.

I’m interested in starting with the experiment-tree lifecycle changes, particularly orx exp move and/or orx exp archive. I’ll first trace the existing experiment store, CLI, API, and dashboard handling of parentExperimentId and run records so the changes preserve existing experiment/run history.

For delete, I’d like to confirm the intended semantics around existing runs, child experiments, and --force before implementing it.

If the maintainers have a preferred smaller scope for a first PR, I’m happy to follow that.

[sox8502]

@tizerluo Thanks for opening this and sorry for such a late response.

I think both an orx move and an orx archive command both make a lot of sense. I've actually been thinking about some sort of archive command for a while to prune and manage growing experiment trees. We'll add functionality to archive the nodes above or below a certain experiment.

For the orx move command, we can implement this so that only the experiment tree and not the git ancestry is changed. This might complicate the experience of viewing diffs for experiments whose nodes have been removed but I think this is worthy tradeoff.

I don't think that an orx delete command makes sense for OpenResearch given how important provenance is to the experience. I think the archive command can address a lot of the pain points that may have motivated an orx delete command.

We plan to have PRs for orx move and orx archive up and merged by EOW. Let me know if you have any thoughts about any of this.