con/serve
Vision #
Note on domain examples: The con/serve platform is domain-agnostic – git-annex, DataLad, and the patterns described here work for any field. Many examples reference neuroscience and psychology because that is our primary domain at the Center for Open Neuroscience, but the tools and architecture apply wherever digital artifacts need archiving.
Research generates far more than code and data. Every Slack thread, Zoom recording, GitHub discussion, AI coding session, and conference PDF is a piece of the scholarly record – and most of it is quietly rotting on someone else’s servers.
con/serve extends YODA principles to all digital research artifacts. If it matters to your work, it belongs in a version-controlled, content-addressed repository where you own the bits, not a SaaS provider.
The core idea is a bidirectional funnel:
- Ingest from dozens of sources – messaging platforms, video hosting, code forges, cloud storage, reference managers, AI assistants – into a git-annex / DataLad vault.
- Conserve and distribute outward to domain archives, cloud backups, institutional knowledge bases, and web publications.
(Slack, Matrix, Email)"] media["Media
(YouTube, Zoom)"] code["Code Artifacts
(Issues, Wikis)"] ai["AI Sessions
(Claude, Cursor)"] pubs["Publications
(Citations, PDFs)"] cloud_in["Cloud Storage
(rclone, 70+ providers)"] comm ~~~ media ~~~ code ~~~ ai ~~~ pubs ~~~ cloud_in end subgraph HUB["THE VAULT"] direction TB ga["git-annex
content-addressed storage"] dl["DataLad
dataset management"] org["YODA / STAMPED
organization & principles"] surfaces["Working Surfaces
(Hugo, HedgeDoc, LLM agents)"] ga --- dl dl --- org dl --- surfaces end subgraph OUT["OUTBOUND"] direction TB archives["Domain Archives
(OpenNeuro, DANDI, OSF)"] backup["Cloud Backup
(S3, Glacier, Dropbox)"] webpub["Web Publishing
(GitHub Pages)"] archives ~~~ backup ~~~ webpub end IN ==>|archive &
import| HUB HUB ==>|publish &
distribute| OUT classDef inbound fill:#2b6cb0,stroke:#2c5282,color:#fff,stroke-width:2px classDef hub fill:#d69e2e,stroke:#b7791f,color:#1a202c,stroke-width:3px classDef outbound fill:#2f855a,stroke:#276749,color:#fff,stroke-width:2px class comm,media,code,ai,pubs,cloud_in inbound class ga,dl,org,surfaces hub class archives,backup,webpub outbound style IN fill:#ebf8ff,stroke:#2b6cb0,stroke-width:2px,color:#2b6cb0 style HUB fill:#fefcbf,stroke:#d69e2e,stroke-width:3px,color:#744210 style OUT fill:#f0fff4,stroke:#2f855a,stroke-width:2px,color:#2f855a
For the full detailed diagram with all tools and connections, see the Architecture section.
See also the closing Beyond YODA slide and video from the YODA & BIDS webinar.
Explore #
| Section | What you will find |
|---|---|
| About | Project vision, principles, and how to contribute |
| Architecture – full system diagram (inbound / vault / outbound) | |
| YODA Principles – how con/serve extends YODA to all artifacts | |
| STAMPED Framework – guiding principles for artifact management | |
| Frozen Frontiers – deliberate working boundaries and compressed context | |
| Privacy & Access – archive aggressively, distribute selectively | |
| Integration Levels – native-datalad, git-annex, git-only, external | |
| AI Readiness – ai-ready, ai-partial, ai-manual | |
| Contributing – how to add tools and content | |
| Tools | Catalog of archival tools organized by artifact type |
| Infrastructure | Self-hosted services for managing and serving archived artifacts |
| Concepts | Cross-cutting patterns for ingestion, conservation, and distribution |
| User Stories | Concrete archival scenarios that drive development – from personal vaults to lab infrastructure |