Documentation/Collections
Shelby Studio Docs

Collections

Collections

Shelby Studio provides a project-aware collection workspace for organizing related digital assets. Collections group assets that belong to the same project or NFT collection while keeping collection information, assets, metadata, branding, and preview functionality within one workspace.

The collection system is part of the broader project-centric architecture and works alongside Storage, Metadata, Projects, and future publication workflows.

Overview

A collection represents a group of related assets managed within a Shelby Studio project. The current collection interface provides components for:

  • Collection information
  • Collection assets
  • Collection metadata
  • Collection branding
  • Collection preview
  • Collection actions
  • Active project context

The collection system provides the organizational layer required to prepare related assets for NFT-oriented workflows.

Architecture

components/collections/
├── ActiveProjectBanner.tsx
├── CollectionActions.tsx
├── CollectionAssets.tsx
├── CollectionBranding.tsx
├── CollectionHeader.tsx
├── CollectionInformation.tsx
├── CollectionMetadata.tsx
└── CollectionPreview.tsx

The collection interface is built from smaller feature-specific components rather than placing all collection functionality inside a single page component. This allows individual parts of the collection workflow to evolve independently.

Collection Structure

Project
│
└── Collection
    │
    ├── Information
    ├── Branding
    ├── Metadata
    ├── Assets
    └── Preview

A collection exists within the context of a project rather than being treated as an isolated global object.

Active Project

The collection workspace is project-aware. The active project provides the organizational context for the collection and its associated assets:

Connect Wallet → Select Project → Open Collection Workspace → Manage Collection

This matters because the same application can contain multiple projects with separate assets and collection workflows.

Core Components

Collection Information

Describes the identity and basic properties of a collection. Typical fields may include:

  • Collection name
  • Description
  • Collection identity
  • Supporting project information

The exact fields are determined by the current collection data model and interface.

Collection Assets

Provides the interface for working with assets associated with a collection:

Collection
   │
   ├── Asset 1
   ├── Asset 2
   ├── Asset 3
   └── ...

Collection assets can originate from the broader project asset workflow. Storage and collection organization remain related but separate responsibilities — Storage determines where an asset is stored; Collections determine how related assets are organized.

Collection Metadata

Collections can contain metadata associated with the collection itself, separate from metadata belonging to individual NFTs:

Collection
│
├── Collection Metadata
│
└── Assets
    │
    ├── NFT Metadata
    ├── NFT Metadata
    └── NFT Metadata

This separation allows collection-level information and individual asset metadata to evolve independently.

Collection Branding

Provides a dedicated area for collection presentation information — the visual identity of a collection within the workspace. Branding is intentionally separated from collection information so presentation concerns don't need to be embedded directly into the underlying asset model.

Future branding workflows may become more closely connected with portfolio presentation and published project views.

Collection Preview

Provides a visual representation of the collection, letting developers inspect how collection information and associated assets come together before moving to later workflows:

Collection Information
        │
        ├── Branding
        ├── Metadata
        └── Assets
              │
              ▼
        Collection Preview

The preview is a presentation layer, not a blockchain publication confirmation.

Collection Actions

Provides controls for managing the collection workflow. The actions layer is separated from presentation components so collection operations can evolve without redesigning the entire collection interface. Available actions depend on the current implementation.

Planned future actions:

  • Collection export
  • Batch metadata generation
  • Collection validation
  • Collection publication preparation
  • Collection duplication

Relationships to Other Systems

Storage

Storage and Collections have different responsibilities — Storage handles decentralized asset storage; Collections handle organizing related assets:

Project
   │
   ├── Storage
   │     ├── Asset A
   │     ├── Asset B
   │     └── Asset C
   │
   └── Collection
         ├── Asset A
         ├── Asset B
         └── Asset C

The same underlying project assets can participate in both storage and collection workflows without the collection system implementing its own storage layer.

Metadata

A collection may contain multiple assets, and each asset may have its own metadata:

Collection
│
├── Asset 1 → Metadata 1
├── Asset 2 → Metadata 2
└── Asset 3 → Metadata 3

The Metadata workspace provides tools for creating and validating individual metadata records. The Collection workspace provides the organizational context for grouping those assets.

Projects

Projects provide the higher-level workspace boundary:

Project
│
├── Assets
├── Storage
├── Metadata
├── Collections
├── Activity
└── Publication

Collections operate as a project-level organizational feature, letting developers manage multiple independent collections without mixing their assets or project state.

Publication

Collections are part of the broader project lifecycle. A future publication workflow may use collection information when determining whether a project is ready for publication:

Create Project → Add Assets → Organize Collection → Prepare Metadata → Validate Project → Publish Project

Creating a collection does not by itself mean the project has been published — publication state must be derived from the project's actual publication information and transaction state.

Collection Workflow

Open Project
     │
     ▼
Create / Manage Collection
     │
     ▼
Enter Collection Information
     │
     ▼
Add Branding
     │
     ▼
Associate Assets
     │
     ▼
Prepare Metadata
     │
     ▼
Review Collection Preview
     │
     ▼
Validate
     │
     ▼
Continue Project Workflow

Not every project must use every step — collections are intended to be modular within the larger Shelby Studio workspace.

NFT-Oriented Workflows

The collection system provides an organizational foundation for NFT development. A collection may eventually contain:

  • Collection identity
  • Collection branding
  • Collection metadata
  • Individual NFT assets
  • Individual NFT metadata
  • Storage references
  • Publication information

This lets Shelby Studio connect storage operations with higher-level NFT preparation without making storage itself dependent on NFT functionality.

Current Implementation

The current collection workspace includes:

  • Active project context
  • Collection information interface
  • Collection asset interface
  • Collection metadata interface
  • Collection branding interface
  • Collection preview
  • Collection actions

These components provide the current foundation for collection management within Shelby Studio.

Current Limitations

The current collection implementation should be considered a development foundation rather than a complete NFT collection management platform. It does not by itself provide:

  • NFT minting
  • Marketplace deployment
  • Collection-wide blockchain indexing
  • Full multi-user collection collaboration
  • Complete collection version history
  • Automatic marketplace synchronization

These capabilities belong to future platform development.

Planned Development

  • Batch Metadata Generation — generate metadata for multiple assets from collection-level data
  • Collection Validation — validate collection-level information and relationships between assets and metadata
  • Collection Export — export collection assets and metadata as a structured package
  • Collection Versioning — track changes to collection information and asset membership
  • Storage Integration — automatically connect collection assets with their corresponding Shelby storage records
  • Publication Preparation — use collection state as part of project publication readiness checks
  • Mint-Ready Packages — prepare assets and metadata in formats suitable for downstream minting systems

Engineering Principles

  • Project-Centric — collections belong to projects and should respect project boundaries.
  • Modular — collection features are separated into dedicated components.
  • Storage-Agnostic — collection organization should not require knowledge of the underlying storage implementation.
  • Metadata-Aware — collections should be able to work with metadata without owning the metadata generation system.
  • Extensible — the current collection model should support future batch operations, validation, export, and publication workflows.

Future Collection Model

As the platform develops, a more complete collection model could look like:

Collection
│
├── Identity
│   ├── Name
│   ├── Description
│   └── Branding
│
├── Assets
│   ├── Asset 1
│   ├── Asset 2
│   └── Asset N
│
├── Metadata
│   ├── Collection Metadata
│   └── Asset Metadata
│
├── Storage
│   ├── Storage References
│   └── Asset Locations
│
├── Validation
│   └── Readiness Information
│
└── Publication
    └── Project Publication

This model provides a path toward more advanced NFT development workflows without requiring the current collection interface to become tightly coupled to blockchain operations.

Summary

Collections provide the organizational layer between individual assets and the larger project workspace. Shelby Studio currently provides collection information, asset management, metadata, branding, preview, and action components within a project-aware interface.

The collection system is designed to work alongside Storage, Metadata, Projects, and Publication while keeping each subsystem responsible for its own domain. Future development can extend this foundation with batch generation, collection validation, export, versioning, storage-aware asset mapping, publication preparation, and mint-ready workflows.

Previous

Metadata

Next

Dashboard