Prompt pools are versioned training data, not reusable text snippets

I treat adaptive prompt pools as versioned training data, not reusable text snippets. Once a system selects, combines, and updates prompts from experience, the pool records decisions about what the system should learn and retain. Calling it a library hides that responsibility. I want provenance, evaluation history, and reproducible snapshots around it — the same disciplines I would demand for a dataset that shapes model behavior.

The distinction starts with what a prompt means in this research. The prompt-pool continual-learning lineage begins with learned prompts for vision transformers, including L2P and its key-based retrieval mechanism. These are not simply instructions someone can paste into a chat window. They are adaptation artifacts. My training-data framing is an operational argument: preserve the examples and decisions that produced the pool, alongside the learned state itself.

Routing makes the collection a system rather than an inventory. L2P retrieves prompts; CODA-Prompt uses differentiable composition; DualPrompt separates shared and specialized prompts. Those designs make selection and sharing part of the behavior being learned. An expert can remain unchanged while a different routing decision changes which inputs reach it. I would therefore version pool membership, prompt artifacts, retrieval keys, and router configuration together, rather than declare the text diff the complete change.

That implies a data model before it implies a user interface. I would give each candidate a persistent identity, record its parent revision and adaptation context, and attach the evaluation evidence used to retain it. A pool snapshot would identify exact members and their compatible routing state. The question is not merely which prompt is current. It is which collection was available when a decision happened, and what evidence justified that collection.

History becomes especially important when prompts are shared. The hub describes Hash through history-aware routing and gradient modulation, while SMoPE includes a dense-then-sparse training curriculum. These mechanisms make learning history relevant to subsequent adaptation. My architectural inference is that restoring prompt contents alone may not restore the learning process. I would explicitly identify which counters, training phases, and update state a method needs to resume, rather than assume every pool is a stateless lookup table.

I also want promotion evidence to preserve the trade-off between learning and retention. The source distinguishes final average accuracy, cumulative average accuracy, and forgetting measures. That is a useful rebuke to choosing whichever revision scores best on the newest task. I would evaluate earlier task groups alongside new ones and retain their separate results. A shared prompt that improves recent inputs while eroding an older capability has changed the product contract, not merely refreshed its wording.

This is where data-platform practice earns its place. The historical identity discussed in memory versioning gives me a useful model for pool membership records. Prompt release semantics supplies the promotion boundary, and evals as a contract supplies acceptance criteria. I would connect those records so an operator can trace a deployed pool back to its adaptation inputs and approval evidence without reconstructing the story from experiment names.

I concede a precise boundary: a fixed collection of manually selected instructions, with no learned routing, composition, or feedback-driven updates, can remain a version-controlled template library. It does not need a continual-learning data pipeline. The threshold is crossed when accumulated experience changes pool membership, expert behavior, or selection policy — when the collection starts carrying learned state rather than merely organizing authored text.

The connection to router-prompt co-evolution in LLM agents makes this distinction worth carrying beyond vision research. I would transfer the ownership questions, not assume identical benchmark results: who controls admission, what preserves older capabilities, and which snapshot explains a decision? The asset is the governed learning history embodied in a pool and its router. Treating that asset as snippets makes reuse convenient while leaving adaptation unaccountable.