Creation of Anemoi sandbox

[anaprietonem]

Is your feature request related to a problem? Please describe.

🧪 Proposal: anemoi-sandbox Repository
Motivation
Motivated by recent discussions around code sharing (e.g., explainability tools in anemoi-inference: ecmwf/anemoi-inference#502) and the need to lower barriers for collaborative experimentation within the Anemoi ecosystem, this proposal suggests creating a new repository: anemoi-sandbox.

This repository would provide a shared space for contributors to experiment, prototype, and share research-oriented code.

It complements the existing plugin architecture by hosting early-stage, experimental, or contributor-specific tools that are not yet mature enough for formal integration but still provide value to the community.

Purpose
anemoi-sandbox is intended as a community-driven repository for:

• Sharing experimental features, tools, and code snippets related to Anemoi
• Prototyping ideas before promoting them to formal contributions
• Providing optional, installable extensions on top of existing Anemoi packages
• Enabling faster iteration and research sharing without formal contribution overhead
  Not intended for:
• Production-ready code (use official Anemoi repositories or plugins instead)
• Features requiring guarantees of support, stability, or maintenance

Scope & Organization
Proposed repository structure:

anemoi-sandbox/
├── training/ # Experimental training utilities
├── datasets/ # Dataset processing prototypes
├── graphs/ # Graph construction experiments
├── models/ # Novel model architectures or layers
├── transforms/ # Data transformation ideas
├── inference/ # Inference-related prototypes
└── tools/ # General-purpose scripts/utilities

Each folder may contain:

• Python modules installable as optional dependencies
• Standalone scripts
• Jupyter notebooks (demos, tutorials)
• Documentation (folder-level READMEs maintained by contributors)

Installation & Usage
Design principle: Each subdirectory should be installable independently on top of the corresponding Anemoi package.

Example:

pip install git+https://github.com/ecmwf/anemoi-sandbox.git#subdirectory=training

For local development:

cd anemoi-sandbox/training
pip install -e .

Difference from Plugins
Plugins:
Mature, tested functionality
Maintained with CI/CD
Broad user relevance
Formal review process

Sandbox:
Experimental, early-stage code
No CI/CD; contributor-maintained
Niche, research, or prototype features
Lightweight contribution process

Contribution & Maintenance Model

• No CI/CD: Contributors are responsible for testing and maintaining their code
• Contributor ownership: Each folder or feature should have a designated maintainer (via CODEOWNERS or README)
• Best-effort support: Maintainers are expected to respond to issues related to their contributions
• Lightweight review: PRs are reviewed for structure and conflicts, not rigorous validation
• No long-term guarantees: Features may become outdated; users must verify compatibility

Governance

• Maintainers: The Anemoi security team provides repository-level oversight but does not maintain individual contributions
• Contribution process:
• PRs should include a short description, intended use, and known limitations
• Follow existing Anemoi conventions on a best-effort basis for consistency
• Feedback and approval are community-driven rather than formalized
• Archiving: Stale or unmaintained contributions may be flagged or moved to an archive/ directory
• Out-of-scope contributions:
• No ATS discussion required by default
• Contributions conflicting with core design principles or raising security concerns may be escalated

Describe the solution you'd like

Describe alternatives you've considered

No response

Additional context

No response

Organisation

No response

[anaprietonem]

Update: after discussing this with the @ecmwf/anemoi_technical_subgroup the outcome is that the creation of sanbox repository for Anemoi should be postponed till there is a clearer use case or example of the features that could leave here. It is not clear how different features implemented for the same repo could co-exist or be used together, and what would be the workflow for updating those.

In that sense, the preference is to wait and gauge interest to identify specific use cases or examples of features that could be considered part of the sandbox, and revisit the topic in the future.