Publish

Collections and research toolkits

What collections are, how they are curated, and how to publish a reproducible toolkit as a bundle.

Two different things help people find sets of artifacts that belong together.

	Collection	Bundle
What	An editorial list on the website	A published artifact of type `bundle`
Who makes it	Registry curators	Any publisher
Versions	None; it changes over time	Versioned and immutable, with exact pins
Use it for	Discovery	Reproducibility

Collections

A collection is a titled, described list of public artifacts, optionally with a curator's note per item. The registry starts with these topics:

Academic Research, Financial Econometrics, Scientific Writing, macOS Automation, Local LLMs, Data Engineering, Developer Productivity, Evaluation.

A collection may be empty. The registry does not fill collections with placeholder entries; a collection shows what has actually been published and selected.

Browse: /collections
API: GET /api/v1/collections, GET /api/v1/collections/{slug}

Only public artifacts appear. If an artifact is taken down, made private or archived, it disappears from the collection automatically.

Suggesting an addition

Curation is done by the registry's administrators in this version. Email contact@spboucher.ai with the artifact name, the collection, and one sentence on why it belongs. Inclusion is an editorial choice, not an endorsement of safety or quality, and is never paid.

Reproducible research toolkits

When you want someone else to get exactly the set of tools behind a paper or a project, publish a bundle.

Publish each component as its own artifact.
Create a bundle whose dependencies pin exact versions:

{
  "schemaVersion": "1.0",
  "name": "@yourns/paper-2026-toolkit",
  "version": "1.0.0",
  "type": "bundle",
  "description": "Skills and evaluation kit used for the 2026 working paper on intraday volatility.",
  "license": "CC-BY-4.0",
  "repository": "https://example.org/you/paper-2026",
  "dependencies": [
    { "name": "@yourns/garch-estimation", "version": "2.1.0" },
    { "name": "@yourns/table-builder", "version": "1.4.2" },
    { "name": "@yourns/replication-kit", "version": "1.0.0" }
  ]
}

In the bundle's README.md, state the environment (clients and versions used), the order of use, the data that is needed and where to obtain it, and the expected outputs.
Cite the bundle by name and version. Because releases are immutable and each has a SHA-256, that citation identifies exact bytes.

Good practice for a toolkit meant to be replicated:

Put the replication materials in an eval-kit artifact: test cases, fixtures, expected results, and instructions to run them.
Do not include data you cannot redistribute. Describe how to obtain it.
Record the commit of your source repository in sourceCommit.
If a component is later revoked, publish a new bundle version; the old one keeps describing what was used at the time.

The registry stores and displays the bundle's pins. It does not install a bundle's components automatically in this version; the bundle page lists each one with its pinned version.