Managing a Cosmetic Catalog Across Multiple Game Seasons

The catalog grows faster than you expect

Season 1 launches with 80 items. Manageable. Season 2 adds 60 more. Still fine. By season 4, you have 300+ variants across 80 assets, some exclusive to past battle passes, some eligible for rerelease, some retired, and some that were commissioned for Season 2 but never shipped. The artist who created them left. The Slack channel where the pricing was discussed was archived.

This is not a hypothetical scenario. It is the normal state of any live game that ships cosmetic content on a seasonal cadence. The catalog does not just grow — it accumulates history, exceptions, and ambiguity. Without deliberate management, the catalog degrades from a useful operational tool into a graveyard of items nobody fully understands.

This article covers the practices that keep a multi-season catalog organized, discoverable, and operationally useful over the long term.

Tagging for seasonal context

Tags are the primary tool for tracking which items belong to which season and under what terms. A minimal tagging strategy for multi-season catalogs:

Season membership

Tag every variant with its origin season: tag "Season", value "3". This is the season the item was created for, regardless of when it actually shipped. An item commissioned for Season 3 but delayed to Season 4 should still be tagged Season 3 — that is its origin context.

In PolyDrobe, tags support optional values, which makes this natural. You can filter the catalog for all Season 3 items in one query, producing the complete roster of what was planned and produced during that period.

Availability classification

Not all items have the same availability rules. Some are permanently available. Some were battle pass exclusives that can never return. Some were limited-time offers that can be re-featured after a cooldown period. Track this with a tag:

• Tag "Availability", value "Permanent" — always available for purchase
• Tag "Availability", value "Battle Pass Exclusive" — locked to the season's battle pass, cannot return
• Tag "Availability", value "Limited" — can return in future rotations after a minimum gap
• Tag "Availability", value "Retired" — no longer available and not planned for return

This classification answers one of the most common liveops questions: "Can we bring this item back?" Without a structured availability tag, the answer requires searching through design documents, Slack threads, or asking someone who may no longer be on the team.

Event association

Items created for seasonal events get an additional tag: tag "Event", value "Halloween 2026" or tag "Event", value "Anniversary Year 2". Combined with the season tag, this lets you query "all Halloween items across all seasons" — useful for planning this year's Halloween event using past events as reference.

The item lifecycle across seasons

A variant's lifecycle does not end at "Released." In a multi-season game, items move through a longer arc:

Concept → In Progress → Review → Approved → Released → Active → Vaulted → (Rereleased | Retired)

The first five statuses are the production pipeline. The last three describe post-launch states:

Active. The item is currently available for purchase or earnable. It might be in the permanent store, the current battle pass, or a rotating offer.

Vaulted. The item has been removed from active availability. It may return in a future rotation, event, or rerelease — but it is not currently obtainable. This is distinct from Retired.

Retired. The item will not return. It is a historical record only. This might apply to promotional items tied to a specific real-world partnership, or battle pass exclusives where the community expectation is that they never come back.

PolyDrobe's status field is configurable per project. You can define statuses that match your game's lifecycle model. The key is that Vaulted and Retired are explicit, queryable states — not an absence of information that forces someone to guess.

When to vault

Items should be vaulted when they have not been featured in the store for an extended period (6+ months) and are not planned for upcoming rotations or events. Vaulting does not delete the item — it changes its status so that rotation planning queries exclude it by default.

Periodic vaulting is like pruning a garden. It keeps the Active catalog focused on items that are actually in play, which makes rotation planning faster and search results cleaner.

When to retire

Retire items when there is a definitive reason they will not return:

• The partnership or licensing agreement has expired
• The community expectation is that the item is exclusive (battle pass items in games that promise exclusivity)
• The item's visual quality no longer meets the game's current standard and updating it is not planned

Retirement should be an explicit decision, not a default. If you are unsure whether an item will return, vault it. You can always promote a Vaulted item back to Active; promoting a Retired item sends mixed signals about exclusivity.

Tracking exclusivity commitments

Exclusivity is a promise to players, and breaking it damages trust. Battle pass items that were advertised as exclusive must stay exclusive. Limited-time items that were marketed as "available for one week only" should not appear in the permanent store a month later without a clear communication to players about the policy change.

The challenge is that exclusivity commitments are often made in marketing copy, community announcements, or design documents that are not connected to the asset catalog. Six months later, a new liveops manager sees a popular Legendary skin in the Vaulted state and asks "can we bring this back?" If the exclusivity commitment is not recorded on the variant record, the answer requires archaeology.

Record exclusivity on the variant. Use the metadata JSON field or a dedicated tag:

• Tag "Exclusivity", value "Battle Pass S2 — Permanent Exclusive"
• Tag "Exclusivity", value "Limited Offer — Can return after 90 days"
• Tag "Exclusivity", value "None — Permanent catalog item"

Or in metadata: {"exclusivity": "Battle Pass S2", "can_return": false, "reason": "Marketed as exclusive in Season 2 trailer"}

This makes the exclusivity commitment discoverable at the moment of decision, not after a Slack archaeology expedition.

Catalog health metrics

A healthy multi-season catalog has quantifiable characteristics. Track these periodically — quarterly at minimum:

Distribution by status

If Active items outnumber Vaulted + Retired, the store may feel overwhelming. If Vaulted dominates, the Active catalog is thin and rotations will feel repetitive.

Rarity distribution per season

Compare rarity distribution across seasons to ensure consistency:

• Season 1: 40% Common, 25% Uncommon, 20% Rare, 10% Epic, 5% Legendary
• Season 2: 35% Common, 20% Uncommon, 25% Rare, 15% Epic, 5% Legendary
• Season 3: 20% Common, 15% Uncommon, 25% Rare, 30% Epic, 10% Legendary

This trend shows rarity inflation — each season skews more toward premium tiers. Left unchecked, this undermines the rarity system's credibility. If everything is Epic, nothing is.

In PolyDrobe, filter by season tag and rarity to generate these counts. Export to Excel for cross-season comparison charts, or use the MCP server to query distribution:

"Compare rarity distribution between Season 2 and Season 3 items. Is there rarity inflation?"

Category coverage per season

Each season should introduce items across categories. If Season 3 added 15 Headwear variants and 0 Accessories, players who prefer accessories had nothing new for an entire season. Track category distribution per season to identify blind spots.

Orphan and incomplete records

Search for variants with missing data: no thumbnail, no price, no rarity, status still Concept from two seasons ago. These are items that fell through the cracks during production. They clutter the catalog and confuse anyone who finds them.

PolyDrobe's search and filtering helps surface these: filter for status "Concept" created more than 90 days ago, or search for variants with no thumbnail. Clean them up — either move them to a backlog, advance them to production, or delete them if they were abandoned.

Institutional memory and team turnover

The most insidious problem with multi-season catalogs is knowledge loss. The producer who knows why the Phantom Jacket was priced at 2500 instead of the standard 2000 for Epic items — they leave. The artist who remembers that the Chrome variant was a collaboration piece with a specific contractual restriction — they move to a different team.

A structured catalog is the antidote:

Activity history. Every field change on every variant is logged with the user, timestamp, and old/new values. When the new producer wonders why the Phantom Jacket is priced oddly, the activity history shows who set the price and when.

Metadata for context. Use the variant's metadata JSON field for context that does not fit standard fields: pricing rationale, collaboration details, references to external agreements, design intent notes.

Tags for classification. Tags like "Exclusivity", "Event", "Season", and "Availability" encode decisions that were made for specific reasons. The tag is the decision; the metadata or activity history explains why.

Consistent naming. If every Season 3 item follows the naming convention "S3 — Item Name — Variant", the season and origin are embedded in the name itself. Future team members can identify origin at a glance without consulting any other record.

None of this requires extra process. It requires using the fields that already exist on the variant record. The marginal effort of writing "pricing_rationale": "Collab with StudioX, premium pricing per contract" in the metadata field is seconds. The cost of not having that information when the question arises six months later is hours.

When the catalog outgrows a single project

Some games reach a scale where a single project cannot hold the entire catalog efficiently. At 1000+ variants, consider splitting by content type:

• Project: Character Skins — outfits, full-body cosmetics
• Project: Accessories — gloves, belts, backpacks, trinkets
• Project: Weapons — weapon skins and charms

Each project has its own taxonomy, team roles, and settings, but the same team members can be invited to all projects. This keeps each project's catalog focused and searchable while allowing cross-project planning via export or MCP queries.

Key takeaways

• Tag every variant with its origin season, availability classification, and event association. These tags answer the most common multi-season questions: "What can we bring back?" and "When was this created?"
• Define explicit post-launch statuses: Active, Vaulted, Retired. Do not let items exist in an ambiguous state where nobody knows if they can return.
• Record exclusivity commitments on the variant record itself — not in marketing copy or Slack threads that nobody will find later.
• Track catalog health metrics quarterly: status distribution, rarity inflation across seasons, category coverage, and orphan records.
• Use activity history, metadata, and consistent naming to preserve institutional memory across team turnover.
• Consider splitting into multiple projects when the catalog exceeds 1000 variants and team workflows diverge by content type.