A task-board export needs an experiment index

A task board can show that work moved and still lose the experiment behind it. You notice this when a project gets exported or archived. The cards keep their titles, assignees, dates and status changes, maybe the attachments too, but why the test was run, what configuration it used and what "done" meant are scattered through comments or sitting in someone's notes. Six months later a completed card can look like proof of something it never tested.

So I'd keep a small experiment index next to the board. Each experiment gets an identifier that works outside the board product (card numbers collide across projects and can vanish in a migration, so a project prefix and a sequence number is enough). The entry starts with the question. "Try new retrieval settings" is an activity. "Does adding document date to retrieval reduce answers based on superseded guidance?" tells you what you're trying to learn. I'd keep the fields to:

• identifier and date
• question or hypothesis
• owner and review status
• input set or evidence source
• configuration and relevant versions
• result, limits and linked artefacts

Write down the plan before you run it: which cases, what changes, what stays fixed and how you'll judge it. That doesn't need to be a lab protocol, it just needs to separate a planned comparison from an interesting output you found afterwards. If you tried several prompts and kept the best-looking one, say that. Configuration also covers more than the prompt, since the model version, retrieval index, tool permissions, source snapshot and app release can all change the outcome. "Tested on customer questions" is too vague and risky. Name an approved fixture set, or a restricted reference that shows which cases ran without copying private content into the index.

The index should link to the outputs, logs, notebooks and pull requests rather than copying them, with enough description that results-final.csv still means something later. Keep private data in its approved system and note the access needed, because a board export often gets shared more widely than the workspace was. For results, "successful" isn't enough. If five defined cases improved and two regressed, write that down. If it was one reviewer's preference, label it that way. Keep the outcome (supported, not supported, mixed, inconclusive) separate from task status, because a card can be complete even though the change failed. Negative and inconclusive results belong in there too, otherwise the next team repeats them.

When a result turns out to be wrong, say a scoring bug, append a correction and link the corrected run rather than quietly editing the old conclusion. Back to the export: the board will still show that cards moved, but without the index nobody can tell what each test asked, how it was set up or what it found, and a completed card ends up standing in for a result. So before retiring the board, I'd pick a few experiments, including one failed test and one adopted change, and ask someone outside the work to find the question, setup, evidence, outcome and decision from the index alone. If they end up digging through chat or asking the original owner what "successful" meant, fix those records while people still remember the work.